Agenta-AI/agenta

JSON Diff: case_insensitive_keys=True scores identical JSON as 0.0 when keys contain uppercase letters The bug is in sdks/python/agenta/sdk/engines/running/handlers.py:252-268 (_compare_jsons). Two callers reach this code: auto_json_diff_v0 (line 1450) match_v0 with match: "diff", through _execute_match_diff, which passes "case_insensitive_keys": not case_sensitive (line 2631) Both settings are opt-in. case_insensitive_keys defaults to False, and match_v0 defaults case_sensitive to True (line 2691). keys = set(flattened_ground_truth.keys()) if settings_values.get("predict_keys", False): keys = keys.union(set(flattened_app_output.keys())) cumulated_score = 0.0 no_of_keys = len(keys) case_insensitive_keys = settings_values.get("case_insensitive_keys", False) compare_schema_only = settings_values.get("compare_schema_only", False) flattened_ground_truth = normalize_keys( flattened_ground_truth, case_insensitive_keys ) flattened_app_ou

What happens Committing a workflow revision with a slug that's already used by another revision in the same project fails with 500 commit_failed: The commit did not produce a revision. The real cause is a unique-key violation (workflow_revisions_project_id_slug_key). The storage layer swallows it and returns nothing, and the router reports a server error. Expected A 409 Conflict that says the slug is already taken, so the caller knows what to change. Notes This isn't new in v0.121.0. The same code path exists in v0.120.0. The builder agent and templates aren't affected, because the server generates a fresh slug when the caller doesn't send one. Direct API callers that send slugs hit it. Found during v0.121.0 release QA.

In the mobile app, if the first message of a brand-new session never reaches the server, reloading that session leaves a "Loading conversation" spinner on screen forever. No error appears, and there is no way forward other than navigating away by hand. Steps to reproduce Open the mobile app and start a new session from the composer. Send the first message with the network unavailable, so the send never reaches the server. The app shows "The message was not sent." Reload the page on that session URL. Expected: the session opens as an empty composer, or says it could not be loaded and offers a retry. Actual: a spinner labelled "Loading conversation" that never resolves. Checked against the database: there are no rows for that session id in any session table, so there is nothing for the client to load. The session id exists only in the browser. Where it comes from Read on release/v0.119.1. A session opened from the composer is minted in the browser before anything is persisted. web/mobi

Reproduction In sdks/python/agenta/sdk/utils/init.py: _host = _api_url.rsplit("/api", 1)[0] ... url = f"{self.host}/api/otlp/v1/traces" The split is not anchored to a path segment, so an internal base whose host is literally api cuts inside the scheme: AGENTA_API_INTERNAL_URL trace endpoint built http://api:8000 http://api/otlp/v1/traces (port lost) http://agenta-api:8000 http://agenta-api:8000/api/otlp/v1/traces The runner then rejects the endpoint because the port differs, drops the run credential, and every turn fails with "This session is already running a turn". Expected Strip only a trailing /api path segment (urlsplit, remove a trailing /api from the path, keep scheme, host and port intact). Context Found while fixing the runner side in #6785. It only bites when the services container is given an internal base with host api and no /api suffix; compose gives the services container the public AGENTA_API_URL so it does not see it today. https://claude.ai/code/session_01

When a form has only one question, the stepper (step/progress indicator on the dock) still shows "1 of 1" or similar. It should be hidden — there is nothing to step through. Expected: No stepper when there is only one question — it is dead UI that adds visual noise. Actual: The stepper shows even for a single question, taking up space. Screenshot: (attach the image from the original report)