[stale] [poc] Add TimeFilter component and integrate time range selection in ObservabilityDashboard and ObservabilityOverview

[jp-agenta]

[STALE][POC] feat(observability): add TimeFilter component and integrate time range selection in ObservabilityDashboard and ObservabilityOverview

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

GitHub CI seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Copilot]

Pull Request Overview

This is a stale proof-of-concept pull request that implements significant refactoring of the evaluations API system, transitioning from a results-based to a steps-based model, removing deprecated functionality, and cleaning up codebase organization.

Key Changes:

• Refactored evaluations API to use "steps" terminology instead of "results"
• Removed deprecated SimpleEvaluations router and legacy applications functionality
• Cleaned up database migration utilities and removed async/await patterns where synchronous is sufficient
• Consolidated imports and restructured entrypoint.py for better organization

Reviewed Changes

Copilot reviewed 111 out of 2320 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
api/oss/src/apis/fastapi/evaluations/router.py	Major refactor replacing "results" with "steps", removing SimpleEvaluationsRouter, updating permissions, and adding archive/unarchive functionality
api/oss/src/apis/fastapi/evaluations/models.py	Updated model names from EvaluationResult to EvaluationStep, renamed metrics models for consistency
api/oss/src/apis/fastapi/annotations/router.py	Complete rewrite integrating tracing service and evaluators router for annotation management
api/oss/src/apis/fastapi/annotations/models.py	Replaced core types with inline definitions, added enums for annotation categorization
api/oss/src/init.py	Simplified email blocking logic by removing async PostHog integration
api/oss/databases/postgres/migrations/utils.py	Converted async database operations to synchronous
api/entrypoint.py	Restructured imports, removed deprecated routers, simplified middleware setup

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The enum names are swapped: span_type_enum is named 'tracetype' and trace_type_enum is named 'spantype'. This should be corrected to match the variable names: span_type_enum should use name='spantype' and trace_type_enum should use name='tracetype'.

Suggested change

	span_type_enum = sa.Enum(SpanType, name="tracetype")
	trace_type_enum = sa.Enum(TraceType, name="spantype")
	span_type_enum = sa.Enum(SpanType, name="spantype")
	trace_type_enum = sa.Enum(TraceType, name="tracetype")

[Copilot]

The hardcoded 'postgresql://' protocol differs from the dynamic DB_PROTOCOL variable used elsewhere. For consistency, use DB_PROTOCOL here as well: f\"{DB_PROTOCOL}://{DB_USER}:{DB_PASS}@{DB_HOST}:{DB_PORT}/{new_name}\"

Suggested change

	new_db_url = f"postgresql://{DB_USER}:{DB_PASS}@{DB_HOST}:{DB_PORT}/{new_name}"
	new_db_url = f"{DB_PROTOCOL}://{DB_USER}:{DB_PASS}@{DB_HOST}:{DB_PORT}/{new_name}"

[Copilot]

Wrong response model used. The function return type is EvaluationQueueIdResponse but EvaluationQueueResponse is being instantiated. This should be EvaluationQueueIdResponse to match the function signature.

Suggested change

	queue_id_response = EvaluationQueueResponse(
	queue_id_response = EvaluationQueueIdResponse(

[Copilot]

Corrected spelling of 'migrations' to 'migratons' in the alias.

To fix this SSRF risk, the code should strictly validate that evaluationTableId is a safe value—either matching a known pattern (e.g. a UUID) or selected from a list of allowed IDs. For this scenario, an effective and minimal mitigation is to ensure evaluationTableId is a string matching the expected format of an evaluation ID (for example, a UUID v4, if that's typical), rejecting any values that don't meet the pattern. This should be implemented in the hook useEvaluationRunData: before using evaluationTableId, validate it and handle invalid IDs appropriately (e.g., skip the request and return null, or log and display an error).

The specific fix is to check that evaluationTableId matches a regex pattern for UUIDs or positive integers (adjust pattern based on what IDs are expected). This validation can be performed just before firing off the axios request in fetchAndEnrichPreviewRun. If invalid, skip the request and do not interact with the backend.

No external libraries are required for simple regex matching.

To fix this SSRF issue, the code must restrict and validate user input before using it in the URL path of a server-side HTTP request. The evaluation ID, received from the query string, should be allowed only if it matches safe, expected formats – e.g., a fixed-length alphanumeric string, UUID, or an ID found in a known allowlist. Client-side validation can supplement backend protections, reducing risk. The best way is to validate all IDs passed into fetchEvaluation, fetchAllEvaluationScenarios, etc. (in web/ee/src/services/evaluations/api/index.ts) to allow only safe values.

Concretely:

• Implement a validation function (e.g., isSafeEvaluationId) that checks each evaluationId for type, length, and allowed characters (e.g., UUID v4 format, or simple regex for alphanumeric IDs).
• Use this function to filter the array passed to fetchAllComparisonResults and propagate through all API calls that use evaluationIds.
• In particular, in fetchAllComparisonResults (and helper functions like fetchEvaluation, fetchAllEvaluationScenarios), reject invalid IDs with an error or by filtering.
• Add this validation function in web/ee/src/services/evaluations/api/index.ts.
• Fix the call in EvaluationCompareMode (in web/ee/src/components/pages/evaluations/evaluationCompare/EvaluationCompare.tsx) to pass only validated IDs to the service function.

This approach preserves original behavior for valid IDs, eliminates attack paths for SSRF, and clarifies acceptable input boundaries.

To fix the vulnerability, restrict the user-controlled evaluationId before it is interpolated into any path, ensuring only expected values (such as UUID strings) are allowed. In fetchAllEvaluationScenarios, validate that evaluationId matches the required format (likely a UUID). If the ID does not match, throw an error or ignore it. This can be done via a regular expression check inside fetchAllEvaluationScenarios. All locations where you iterate over evaluationIds (from query string) must ensure this validation as well, so it is best to centralize it in one place.

File/region to change:

• web/ee/src/services/evaluations/api/index.ts: Before using evaluationId in the outgoing request inside fetchAllEvaluationScenarios.
• Add a helper function in the same file to check if a string is a valid UUID (or the correct ID format).

What is needed:

• Add a UUID validation helper (either custom regex or by using a well-known utility).
• Use the helper in fetchAllEvaluationScenarios to ensure only valid IDs are used — throw an Error (or return empty) if invalid.
• Optionally, filter the input array to only process valid IDs in fetchAllComparisonResults.

---

To fix this SSRF vulnerability, we should strictly validate the scenarioId before using it in a URL for an outgoing request. The best way is to ensure that scenarioId conforms to the expected format (almost certainly a UUID v4—since the codebase uses UUIDs generically) before including it in the request path. We can use a regular expression to verify the UUID format: /^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$/. If the value fails validation, we should throw an error, or at minimum, skip making the external request.

Specifically:

• In file web/ee/src/services/evaluations/workerUtils.ts, inside updateScenarioStatusRemote, ensure scenarioId is a valid UUID before using it in fetch URLs.
• The easiest way is to add a helper function in that file, above or inside the method, to check that scenarioId meets the expected criteria.
• If not valid, log (in dev) and return early—do not send fetch requests with tainted data.

---

The best way to fix this problem is to validate and sanitize evaluationId before using it to construct outgoing requests. Since it's expected to represent a resource ID, restrict its format to a known-safe pattern (e.g., Mongo ObjectId, UUID). If it fails validation, prevent the axios request or gracefully handle the error.
Specifically, in fetchLoadEvaluation(evaluationId: string), add a validation step before interpolating it into the URL. If evaluationId is not a valid ID, return null or throw an error before reaching axios.
You'll need to:

• Add a helper to validate the evaluationId format (for MongoDB ObjectId: length 24, hex string; for UUID: RFC4122 format; choose as appropriate).
• In fetchLoadEvaluation, check format before making the axios request.
• Optionally, inform upstream consumers (in hooks/components) if provided ID is invalid.

---

To fix the "externally-controlled format string" issue, we should avoid embedding externally-controlled values (like evaluationId from query parameters) within a format string that is passed along with other arguments to console.error. Instead, the untrusted input should be passed as an argument corresponding to a safe string placeholder ("%s") or, more simply, the first string argument should contain any format specifiers explicitly, and all untrusted values should be provided as separate arguments.

In this code (web/ee/src/services/human-evaluations/api/index.ts), change

console.error(`Error fetching evaluation ${evaluationId}:`, error)

to

console.error("Error fetching evaluation %s:", evaluationId, error)

This way, the format string is fixed, and evaluationId is injected as a value, avoiding any unexpected result from user-controlled format specifiers.

No new methods or special imports are needed; this is purely a string formatting change.

---

The main goal is to restrict evaluationTableId to a safe, expected format (e.g., a UUID, a database string ID) before incorporating it into the request path. To do this:

• Sanitize the evaluationTableId parameter in fetchAllLoadEvaluationsScenarios(). Ideally, restrict it with a regex to safe characters (commonly alphanumeric, dash, underscore).
• If the project expects DB ids to be UUIDs (or similar patterns), only accept matching patterns, otherwise restrict to a conservative charset.
• If invalid, raise or handle the error gracefully (e.g., throw or return an empty result).
• Consider applying the same restriction at the top of the chain (in the hook, or as close to the origin as possible), but since we can only change shown snippets, we do it in fetchAllLoadEvaluationsScenarios itself.
• No new methods or external packages are strictly required for basic validation.

---

To fix this issue, we need to ensure that evaluationScenarioId (and ideally also evaluationTableId) are validated before they are used as part of a URL in the outgoing HTTP request. The safest approach is to restrict these IDs to a safe set of characters, such as only alphanumeric (and hyphens/underscores if required), matching the format such IDs are expected to have in the application (ideally, they should be UUIDs or database-generated IDs). This prevents attackers from injecting special characters, slashes, or sequences such as "../" into the URL, which could allow SSRF or path traversal.

The fix will be implemented in web/ee/src/services/human-evaluations/api/index.ts within the updateEvaluationScenario function. We will add a simple validation (e.g., a regex test) for evaluationScenarioId and evaluationTableId at the beginning of the function. If validation fails, the function will throw an error, thereby blocking the request and preventing any risky URL construction.

No external dependencies are required; we can use JavaScript's built-in regex support.

---