Skip to content

feat(explorer): read prompt-response trajectory URLs under either key - #102

Merged
earakely-scale merged 1 commit into
mainfrom
edgararakelyan/explorer-trajectory-urls
Oct 7, 2026
Merged

earakely-scale merged 1 commit into
mainfrom
edgararakelyan/explorer-trajectory-urls

Conversation

@earakely-scale

@earakely-scale earakely-scale commented Oct 7, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

Core now writes a prompt response's trajectory URLs under object-store names (agent_trajectory_object_url, target_agent_per_turn_trajectory_object_urls) beside the S3-named keys (#101). This is the explorer side: it reads either.

  • lib/trajectory-url.ts: trajectoryUrl and perTurnTrajectoryUrls read the S3-named key first while both are written, falling through to the object-store name when it is null or missing. That is the order core's read_dual_keyed uses. A per-turn entry that isn't a URL stays null, as a failed turn's upload is today, and an empty S3-named list stays empty.
  • Callers: the task-instance viewer (the trajectory list, its refresh signature and hasTrajectories), the tab bar's downloads and the runner's materialized conversation all go through it. An instance recorded under either key shows its trajectories, downloads and turns.
  • Cleanup: the viewer's compact_trajectory_s3_uri type field goes. Nothing read it, and core no longer sets it on a response.

Internal names such as s3Uri / _entryS3Uri are unchanged here; renaming them is wording, done separately.

No release needed: the UI source is excluded from the wheel.

Testing

  • Smoke (npm run test:smoke): 14 ran, 2 skipped on their allowed capability reasons, 0 failed.

    • New trajectory-url.smoke.ts covers:
      • the URL and per-turn URLs read under either key, with a failed turn kept as null;
      • the S3-named key winning when the two differ, including an empty per-turn list;
      • a null S3-named key falling through, and no keys or a non-string URL giving nothing;
      • materializeInstance building its turns from either key.
    • bar-downloads.smoke.ts lists trajectories recorded under either key.
  • Typecheck, lint (no new warnings) and static export: pass.

  • Chaos (built UI in headless Chrome, agent-env up on local stores, this branch vs main): each case is a task instance whose trajectories each carry a unique marker. The check is which object URLs the page fetched and which markers rendered.

    Case This branch main
    S3-named keys only; both keys equal renders renders
    Object-store names only renders no Trajectory tab
    Keys disagree the S3-named one renders; the other is never fetched same
    S3-named key null, other set renders the other no Trajectory tab
    Multi-turn, object-store names, a failed (null) turn Turn 1/3 and 3/3 render, the failed turn is skipped no Trajectory tab
    Empty S3-named per-turn list, stale other list the single URL renders; the stale turn is never fetched same
    Non-string URLs (a number, an object, a string per-turn list) no tab, nothing fetched fetches [object Object] and shows a store error
    Four responses, keys mixed across them all four sections render; the bar collapses to a 4-file dropdown only the two S3-named sections
    Object-store URL with no object "no object at the given object_url", no crash no Trajectory tab
    Written through core 0.9.1289's own persistence (multi-turn) both turns render same
    A running instance gains a response under the object-store name, then the row is re-expanded the new section appears and renders (not read)

    No uncaught exceptions or console errors from the app in any case.

  • Mutants (out-of-tree): 9 of 10 caught.

    • Caught: reading only the S3-named key, reading neutral-first, letting an empty per-turn list fall through, dropping failed turns, keeping a non-string URL, and reverting the bar downloads or either materialize read.
    • The miss is equivalent: || for ?? differs only when the S3-named key is an empty string, which nothing writes.

🤖 Generated with Claude Code

RetriggerConfidence Score: 5/5

The PR appears safe to merge; no actionable issue was found.

Summary

The explorer now reads prompt-response trajectory URLs under either the S3-named or object-store-named fields, preferring the S3-named value when both are present.

  • The explorer finds trajectory URLs under either stored field name.
Diagram
%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Prompt response] --> B[Read S3-named key first]
  B --> C{Missing or null?}
  C -- Yes --> D[Read object-store key]
  C -- No --> E[Use S3-named value]
  D --> F[Viewer, downloads, runner]
  E --> F
Loading

Reviews (1) · Last reviewed commit: "feat(explorer): read prompt-response tra..." · Reviewed by Greptile

The explorer reads a prompt response's trajectory URL and per-turn URLs through one accessor,
lib/trajectory-url.ts: the S3-named key first while both are written, falling through to the
object-store name when it is null or missing, as core reads them. The task-instance viewer, the
tab bar's downloads and the runner's materialized conversation use it, so an instance recorded
under either key shows its trajectories. The viewer's unused compact_trajectory_s3_uri field goes.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@earakely-scale
earakely-scale requested a review from a team as a code owner October 7, 2026 20:20
@earakely-scale
earakely-scale merged commit 044b119 into main Oct 7, 2026
14 checks passed
@earakely-scale
earakely-scale deleted the edgararakelyan/explorer-trajectory-urls branch October 7, 2026 21:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant