(bug) Agent version resets to "version 1" after navigating to settings and back

[ashrafchowdury]

When I go to the settings page from the agent playground, and the agent has more than 1 version, after coming back from settings to that agent, the agent version changes from "latest" to "version 1".

Steps to reproduce:

1. Open an agent in the playground that has more than 1 version.
2. Confirm the version selector shows "latest" (the default).
3. Navigate to the agent's settings page.
4. Navigate back to the agent playground.
5. Observe the version selector — it now shows "version 1" instead of "latest".

Expected: The version selector should preserve the previously selected version ("latest") after navigating away and back.

Actual: The version reverts to "version 1" as if the selected version state is lost on navigation.

[linear-code]

AGE-4243

[dosubot]

@ashrafchowdury, I traced through the playground code and can see the root cause of this bug.

When the Playground component mounts, appSchemaMiddleware reads the revisions query parameter from the URL via getRevisionIdsFromUrl(router). If that param is empty, it falls back to priorityRevisions[0]?.id [1]:

const selectedIds =
    neededRevisionIds.length > 0
        ? neededRevisionIds
        : [priorityRevisions[0]?.id]

The problem is that the "latest" selection is a UI default — it's never persisted to the URL. Looking at Playground.tsx, the effect that writes selected revisions into router.query.revisions [2] only fires when variants are explicitly selected. If the user relies on the default "latest" behavior without interacting with the version selector, the revisions query param stays empty.

So when the user navigates to Settings and back, the Playground unmounts and remounts, the middleware fetcher runs from scratch, finds router.query.revisions empty, and falls back to priorityRevisions[0]?.id. The priority revisions are fetched from variants sorted by updatedAtTimestamp descending [3], and only revisions matching the (empty) revisionIds filter pass through. This means the fallback doesn't use the isLatestRevision flag — it just grabs whatever priorityRevisions[0] happens to be, which ends up being version 1 instead of the actual latest.

In short: the "latest" state lives only in memory during that mount cycle, isn't round-tripped through the URL the way explicit revision picks are, and gets recomputed with a different fallback (priorityRevisions[0] rather than the isLatestRevision-flagged revision) after remount.

A fix would likely need to either:

1. Write the "latest" revision ID into the URL query param on initial load (so it survives navigation), or
2. Change the empty-revisionIds fallback in fetchPriorityRevisions/appSchemaMiddleware to explicitly select the revision marked isLatestRevision instead of just [0].

This is also related to a similar issue around keeping tabs on the latest version tracked in AGE-4222.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Aman-goel-04]

@ashrafchowdury, Can I take this one?

[Aman-goel-04]

@ashrafchowdury Hey, sorry, but I’m not able to reproduce the issue. I tried running the agent with a free model through OpenRouter, but the model has a token limit that prevents me from reproducing the issue reliably.

Since I don’t currently have access to a paid LLM API, I won’t be able to properly reproduce and fix this. I apologise.