Skip to content

Assert bridge opt-ins at request and storage boundaries - #599

Open
bringhurst wants to merge 2 commits into
3.9-li-bridge/verifier-process-isolationfrom
3.9-li-bridge/request-gate-regressions
Open

bringhurst wants to merge 2 commits into
3.9-li-bridge/verifier-process-isolationfrom
3.9-li-bridge/request-gate-regressions

Conversation

@bringhurst

Copy link
Copy Markdown
Member

The final gate audit found that several matrix entries named helper or enabled-path tests, not assertions at the disabled runtime boundary. Add those assertions without changing runtime behavior or the client profile.

  • Recommended election: gate off/on, authorization denial, and unchanged native preferred election.
  • Metadata exclusion: both the request field and broker flag are required.
  • Legacy follower recovery: reject -104 while disabled or below ListOffsets v7; preserve native error handling and the enabled legacy error code.
  • Reassignment cancellation: a real controller resumes a pending assignment with one original replica offline. Default-off accepts native cancellation; opt-in rejects it and retains the pending target.
  • Minimum log roll: an explicit nonzero setting does not leak through a disabled compatibility flag.
  • Leader transfer: opt-in controls both transfer submission and suppression of native ISR shrink.
  • Dynamic scope: test all 24 flags individually so one rejected property cannot hide another wrongly accepted per-broker override.

The focused selector also includes the existing recommended-election request decoder and live/ISR eligibility tests, plus the new cancellation integration test.

Evidence:

  • 441 affected cases pass on Scala 2.12; 39 scoped cases pass on Scala 2.13. No failures/errors/skips.
  • 85 Python tests and actual RAT pass.
  • Three local mutation runs deliberately broke seven guard boundaries. All failed at the intended assertions. Runtime files were restored, compared to HEAD, and tests rerun; no mutation is in this PR.
  • The complete unchanged-profile verifier on runtime f919812 / 8086d17 / wrapper 1764cc95 passed, followed by an independent strict clean/full/archive audit. This test-only follow-up adds separate coverage of the same runtime code.

No broker/client code, schema, setting, deadline or record check is changed. F28's pre-existing client-bootstrap limitation and client-floor decision remain open. Based on #598.

@bringhurst
bringhurst added this pull request to stack #582 September 12, 2026 01:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant