chore: remove obsolete v3/v4 version copy from the dashboard

[claude]

Requested by Chris Arderne · Slack thread

✅ Checklist

• I have followed every step in the contributing guide
• The PR title follows the convention.
• I ran and tested the code works

---

Before / after

Engine V1 (v3) execution is gone, so every "you need V4 for this" notice in the dashboard was decorating a feature that everyone already has.

Before

• Opening the environment selector on a project with no branches said "Branches are only available when using V4 or above. Read our v4 upgrade guide to learn more." Branch availability is actually decided by your plan and whether the environment is branchable — never by the engine version — so the sentence explained the wrong thing.
• The two branches blank-state panels repeated the same claim, one of them ("You must be on V4 to access preview branches") sitting directly next to a Upgrade billing button, which pointed at two different reasons at once.
• Waitpoint Tokens, Preview branches and Dev branches carried a small V4 badge in their page titles, with a tooltip reading "This feature is only available in V4 and above." — even though the nav entries leading to them were never gated on version.
• The side menu showed an amber "V3 deprecation warning" panel saying "V3 deploys will stop working on 1 April 2026. Full shutdown is 1 July 2026…". Both of those dates are now in the past.
• The queues page could render a "New queues table — Upgrade to SDK version 4+ to view the new queues table…" callout with a screenshot.

After

None of the above appears. The branch panels keep the sentence that explains what branches are and drop the version claim; the panel whose real gate is the plan lets its title and Upgrade button carry that on their own, rather than asserting a second, wrong reason. Page titles are plain text. The side menu ends at the incident panel. The queues page always renders the queues table.

Scope

This is copy removal plus the dead code that removal leaves behind. The test-task and replay forms are not touched. An earlier revision of this branch also deleted the allowArbitraryQueues flag those two paths use to swap the queue Select for a free-text Input. That was wrong: the dropdown is fed by a query that hard-filters version: "V2", so on an engine V1 environment the list comes back empty and the free-text input is the only way to set a queue at all. Both paths keep their existing behaviour, and TestTaskPresenter.server.ts, resources.taskruns.$runParam.replay.ts, ReplayRunDialog.tsx and the test-task route are back to zero diff against main.

How

• Deleted apps/webapp/app/components/V4Badge.tsx (V4Badge + V4Title) and unwrapped its call sites in waitpoints.tokens, branches (two arms) and dev-branches routes so each is a plain <PageTitle title="…" />.
• Removed the branch copy from components/navigation/EnvironmentSelector.tsx and both panels in components/BlankStatePanels.tsx, plus the imports that went with it.
• Removed V3DeprecationPanel, V3DeprecationContent, isV3Project, V4_RELEASE_DATE, isLikelyV3 and the mount site from components/navigation/SideMenu.tsx, and dropped engine / createdAt from SideMenuProject now that nothing reads them.
• Removed EngineVersionUpgradeCallout and both code === "engine-version" call sites from the queues route. That took the last reference to assets/images/queues-dashboard.png with it, so the screenshot is deleted too, along with QueuesHasNoTasks in BlankStatePanels.tsx — the removed failure UI was its only renderer, and it is unreachable without it.
• Removed the code: "engine-version" producers from QueueListPresenter.server.ts and QueueRetrievePresenter.server.ts, and moved that check up into the two API route handlers. GET /api/v1/queues and GET /api/v1/queues/:queueParam still call determineEngineVersion and still answer an engine V1 project with 400 {"error": "engine-version"}, unchanged — that is a reachable clean-4xx path for clients still on v3, and only the dashboard's rendering of it was removed. In QueueRetrievePresenter the queue-not-found failure arm survives, so api.v1.queues.$queueParam.ts returns the 400 before the presenter runs and maps the presenter's one remaining failure to 404. In QueueListPresenter engine-version was the only success: false producer, so with the check hoisted the result type collapses to a single object shape; api.v1.queues.ts, the queues resource route, the runs AI-filter route and the queues page were updated to match.
• Simplified the two project.engine === "V2" guards that engine V1's removal made constant, in the runs index route and the side menu.

None of these are part of the deprecation boundary described in .claude/rules/legacy-v3-code.md — they are display affordances, not reject-cleanly paths. The V1 branches in engineDeprecation.server.ts, engineVersion.server.ts, triggerTask.server.ts, cancelTaskRun.server.ts, rescheduleTaskRun.server.ts, initializeDeployment.server.ts and handleWebsockets.server.ts are untouched, as are the historical-data paths in SpanPresenter, ApiRetrieveRunPresenter, replayTaskRun and the admin debug views.

Reviewing tip: the queues route shows a large diff that is almost entirely re-indentation from unwrapping conditionals. Add ?w=1 to the Files-changed URL — the real change there is 13 added / 95 removed lines.

Left for follow-up

Deliberately out of scope here:

• The eleven docsPath("v3/…") link targets (tasks.scheduled.$taskParam, schedules.new, test.tasks.$taskParam, tasks.dashboard, components/runs/v3/TaskRunsTable.tsx, BlankStatePanels). They resolve, but via two redirect hops.
• The batchVersion === "v1" tooltip on the batches page, "Upgrade to the latest SDK for batch statuses to appear." The gate is live legacy data, but the advice is stale — a v1 batch is a historical record that upgrading cannot fix. That is a rewording, not a removal.
• The @trigger.dev/sdk/v3 warning in SetupCommands.tsx, which is still useful guidance inside an agent-rules prompt.
• "Beta upgrade guide" on OUTDATED_SDK_VERSION in packages/core — stale branding rather than a v3/v4 specifier, and it would turn this into a mixed PR.
• Changelogs, test fixtures and migrations mentioning v3/v4.

One thing noticed while working that was not in scope: WaitpointListPresenter.server.ts still returns "Upgrade to SDK version 4+ to use Waitpoint tokens." behind an engineVersion === "V1" check — the same shape as the queues callout removed here, worth the same treatment.

pauseQueue.server.ts keeps its code: "engine-version" rejection, and so do the two queues API endpoints — that is API behaviour on the clean-4xx boundary, not dashboard copy.

---

Testing

pnpm run typecheck --filter webapp passes, and pnpm run lint is clean after pnpm run format / pnpm run lint:fix. Not exercised in a running dashboard.

---

Changelog

Out-of-date upgrade prompts no longer appear in the dashboard: the "V4" badges, the notices saying preview branches and the queues table need V4, and the v3 deprecation warning in the side menu have all been removed.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 42d6b54

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[devin-ai-integration]

Devin Review found 1 new potential issue.

[devin-ai-integration]

🔍 allowArbitraryQueues cleanup claimed in the description was not actually made

The PR description says the engine === "V1" → allowArbitraryQueues derivations and their plumbing through the test-task forms and ReplayRunDialog are gone, but they still exist: apps/webapp/app/presenters/v3/TestTaskPresenter.server.ts:238, apps/webapp/app/routes/resources.taskruns.$runParam.replay.ts:165, and the consumers in apps/webapp/app/components/runs/v3/ReplayRunDialog.tsx:391 and the test-task route. Either the description is stale or part of the intended change was dropped before pushing — worth confirming which.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[claude]

The derivations are retained deliberately: the queue dropdown is fed by QueueListPresenter, which hard-filters version: "V2" (apps/webapp/app/presenters/v3/QueueListPresenter.server.ts:73), so on an engine V1 environment the Select would come back empty and the free-text Input behind allowArbitraryQueues is the only way to set a queue at all — TestTaskPresenter.server.ts, resources.taskruns.$runParam.replay.ts, ReplayRunDialog.tsx and the test-task route are all at zero diff against main on this head. The description was already corrected before this review landed; its ## Scope section now states that those two paths are untouched and explains why the earlier removal was wrong.

---

Generated by Claude Code