You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Compare the v2 manifest's /versions answers with the old gateway's, and answer /ping in the entrypoint #931
The Simulation Entrypoint forwards GET /versions, GET /versions/{kind} and POST /ping to the old gateway, which answers /versions from v1's routing state. The migration plan moves these routes to the v2 version manifest, so that the Public API's release checks no longer depend on the old gateway. Before /versions changes source, staging has to show that the manifest gives the same answers.
This issue covers the first part:
POST /ping answered by the entrypoint itself, with the same answer the old gateway gives (the request's value plus one).
The answers the v2 version manifest gives for /versions and /versions/{kind}, served on internal routes while the public routes keep forwarding.
A comparison of the two sources on every staging deploy, written to the job summary.
Switching the public /versions routes to the manifest is not part of this issue. The Public API reads /versions while serving requests, not only in its release checks, and the manifest cannot yet give the same answers: it names v2 worker applications instead of v1 ones, it records no SPM capabilities, and it has no entries for versions published before it existed. Those need decisions before the switch.
Scope update: this issue covers the comparison step only, as #934 builds it. That means POST /ping answered by the entrypoint, the v2 manifest's /versions answers on internal routes, and a report-only comparison on each staging deploy.
Switching the public /versions routes to the v2 manifest is a separate, later change. It comes after the Public API's v1 economy and budget-window routes are removed. Those routes put the worker application name into the key they store results under, and they recalculate a stored result whenever that name differs from the one the old gateway reports. Switching earlier would therefore recalculate on every read.
As part of that later change:
the v2 manifest will record each bundle's SPM capabilities;
what /versions answers for versions published before the manifest existed will be decided, once request logs show whether anything still asks for them.
Activity
anth-volk commentedon Oct 27, 2026
Scope update: this issue covers the comparison step only, as #934 builds it. That means
POST /pinganswered by the entrypoint, the v2 manifest's/versionsanswers on internal routes, and a report-only comparison on each staging deploy.Switching the public
/versionsroutes to the v2 manifest is a separate, later change. It comes after the Public API's v1 economy and budget-window routes are removed. Those routes put the worker application name into the key they store results under, and they recalculate a stored result whenever that name differs from the one the old gateway reports. Switching earlier would therefore recalculate on every read.As part of that later change:
/versionsanswers for versions published before the manifest existed will be decided, once request logs show whether anything still asks for them.