Repository navigation
Remove McpAccess::legacy_mode consumption in the first release after 0.10.0 #1009
Description
The control plane stopped emitting the mcp_access "mode": "deny" tombstone when the compat floor moved to v0.10.0 (api7/AISIX-Cloud#1355). The data plane still consumes-and-ignores that key as McpAccess::legacy_mode.
It was deliberately kept for one release: documents written before the run-once reprojection re-stamps them still carry mode, so removing the reader in the same release would have made those in-flight rows fail to parse.
Due: the first release after 0.10.0 — whatever its number turns out to be. Do not read this as "0.11.0"; the next version may well be 1.0.0. The condition is "one release has shipped since 0.10.0", not a particular number.
What to do
- Remove
legacy_modefromMcpAccessand the code that tolerates it. - Confirm no strict-schema entry still permits
modeundermcp_access. - A key whose stored document still carries
modeafter this lands would have its row rejected — check whether any path can still produce one before removing.
Filed because this only existed in code comments and a PR description, so it would otherwise be carried silently into a release nobody planned it for.
Activity
[-]Remove McpAccess::legacy_mode consumption at 0.11.0[/-][+]Remove McpAccess::legacy_mode consumption in the first release after 0.10.0[/+]feat(compat): make time-boxed compat code come due mechanically (#1011)
jarvis9443 commentedon Aug 20, 2026
This deadline is now enforced instead of remembered — #1011 put a marker on the field itself:
crates/aisix-core/tests/compat_debt.rsruns in the requiredrust unit + coveragejob and fails every PR once a stable tag with a higherMAJOR.MINORthan 0.10.0 exists — 0.11.0 or 1.0.0, whichever it turns out to be, which is the whole reason the marker names 0.10.0 rather than a prediction. Release candidates don't count as shipped.Two things the gate still can't do, so this issue stays the place for them: it fires only once that next release has already shipped (the
aisix-releasePhase 0 sweep is what catches it in the release it's due in), and it can't check the "confirm no path can still produce amodekey" step above — that judgement is still ours.