GeezerVison is showing github.com — fix(templates): register the local Agentex tracing processor so the developer UI traces tab shows spans by michaelxu2288 · Pull Request #512 · scaleapi/scale-agentex-python
Conversation
Problem
The README's quickstart ends with "Investigate your agent's behavior by opening the traces tab", but every agentex init framework template registers only SGPTracingProcessorConfig, which disables itself when SGP_API_KEY / SGP_ACCOUNT_ID are empty. No other code creates a tracing processor (TracingProcessorManager starts with an empty list), so the spans the unified harness derives are never written to the backend /spans API and the traces sidebar shows "No spans found for this task" for any locally scaffolded agent.
Repro: agentex init (Sync ACP + Claude Code, or any framework), run it against ./dev.sh, send a message, GET /spans?task_id=<task> -> [], backend log has no POST /spans.
Fix
Register AgentexTracingProcessorConfig() ahead of the SGP block in all 16 framework templates (sync / default / temporal x openai-agents, pydantic-ai, langgraph, claude-code, codex, plus the OpenAI local-sandbox variant). SGP registration is unchanged. Fixes a comment in sync-langgraph that claimed to register the Agentex processor while registering SGP. Adds a parametrized test in tests/lib/cli/test_init_templates.py asserting every framework template registers the local processor.
Verification
tests/lib/cli/test_init_templates.py: 42 passed (26 existing + 16 new).
- All 19 templates rendered through
create_project_structure and byte-compiled.
- Fresh agent scaffolded from the patched
sync-claude-code template against a local backend: message -> POST /spans, GET /spans?task_id=... returns the message (AGENT_WORKFLOW) span. Same for a temporal-claude-code agent (Turn 1/2/3 spans via the worker). Without the change: 0 spans.
Follow-ups (not in this PR)
- 22 tutorial/demo files under
examples/ register SGP only, and 00_sync/020_streaming (which the README tells users to copy) registers nothing; happy to mirror this change there.
- Alternative that fixes everything at once: have the SDK auto-register the Agentex processor when
AGENTEX_BASE_URL is set (idempotent, env kill-switch). That changes runtime behaviour for existing agents, so I kept this PR template-only; maintainers' call.
Confidence Score: 3/5
This PR is not safe to merge until locally scaffolded agents send spans to the local backend when AGENTEX_BASE_URL is unset.
What we checked:
- Disabled backend still exports spans: No. The template skips processor registration when the URL is an empty string.
Summary
Scaffolded agents now send spans to the local Agentex backend, and task/create waits until its workflow starts. The PR also updates the SDK’s production URL and changes release and CI workflows.
- Adds local tracing registration to all 16 framework templates while keeping SGP tracing.
- Makes task creation wait for its handler, while event sending stays asynchronous.
- Updates the SDK’s production endpoint and adds repository release and CI automation.
Diagram
%%{init: {'theme': 'neutral'}}%%
flowchart LR
A[Scaffolded agent with URL unset] --> B[Template enables tracing]
B --> C[Processor creates Agentex]
C --> D[Client selects production URL]
D --> E[Span request goes to production]
Loading
Reviews (3) · Last reviewed commit: "fix(templates): skip the local tracing p..."
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
greptile-apps[bot] reacted with thumbs up emoji
Uh oh!
There was an error while loading. Please reload this page.
|
P1 This registers the Agentex tracing processor that #517 removes, and scaleapi/scale-agentex#430 deletes the server-side spans API it writes to, so whichever merges second leaves every scaffolded agent failing at import. The developer UI traces tab is served by #430's platform-backed reader instead, so this needs rebasing to the SGP processor only or closing as superseded.
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
…eveloper UI traces tab shows spans
Every framework template registered only SGPTracingProcessorConfig, which
disables itself when SGP_API_KEY or SGP_ACCOUNT_ID is empty. Nothing else
creates a tracing processor, so spans derived by the unified harness were
never written to the backend /spans API and a scaffolded agent always showed
"No spans found for this task" in the developer UI, contradicting the README
("open the traces tab").
Register AgentexTracingProcessorConfig() ahead of the SGP block in all 16
framework templates (sync/default/temporal x openai-agents, pydantic-ai,
langgraph, claude-code, codex, plus the local-sandbox variant), fix a
sync-langgraph comment that claimed to register the Agentex processor, and
add a parametrized test asserting every framework template registers it.
Verified on a scaffolded sync Claude Code agent and a Temporal Claude Code
agent against a local backend: with the registration, message/turn spans
appear via POST /spans; without it, none do.
Claude-Session: https://claude.ai/code/session_01HCVKnA7LeJZ44nxZz1uzF3
…disabled
The runtime treats an explicitly empty AGENTEX_BASE_URL as "no backend" and
skips agent registration; registering the Agentex tracing processor
unconditionally would then make every span export fail. Guard the
registration on the same condition in all 16 framework templates.
Claude-Session: https://claude.ai/code/session_01HCVKnA7LeJZ44nxZz1uzF3
Comments Outside Diff
These findings could not be posted inline.
-
Local spans go to production src/agentex/_client.py:74 ▶
When a scaffolded agent runs without AGENTEX_BASE_URL, its template turns on local tracing. The tracing processor creates Agentex() without a URL, so this new default sends span requests to production instead of the local backend. The local traces tab stays empty, and span inputs and outputs go to the wrong endpoint. Make the tracing client's endpoint match the backend used by the agent.
How this was verified: The template enables tracing when the URL is unset, and the processor sends span content through a client that now defaults to production.
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
Thanks for flagging this. #517 and scaleapi/scale-agentex#430 were both closed without merging on 09-15, and AgentexTracingProcessorConfig is still on main, so the import concern doesn't apply right now. I've rebased this onto main now that next is retired, and the templates still skip the Agentex processor when AGENTEX_BASE_URL is set to an empty string.
If the Postgres spans API is still on its way out, I'm happy to close this or rework it against whatever replaces it. Just let me know which you'd prefer.
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
This branch has not been deployed
No deployments
Reviewers
At least 1 approving review is required to merge this pull request.
Uh oh!
There was an error while loading. Please reload this page.
Assignees
No one assigned
Milestone
No milestone
Development
Successfully merging this pull request may close these issues.
Uh oh!
There was an error while loading. Please reload this page.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
|