Repository navigation
ci: delete the type-forward allow entry that went stale the moment #2771 merged - #2783
Merged
Merged
Conversation
merged `scripts/type-forwards.allow` still lists MeshWeaver.Fixture:MeshWeaver.Fixture.ObservableAwait but #2771 has merged, so that move is IN main. The gate compares against the MERGE BASE, so relative to any branch cut after #2771 nothing of that name moves — and the entry is reported as STALE: STALE ALLOW ENTRY: scripts/type-forwards.allow lists `MeshWeaver.Fixture:MeshWeaver.Fixture.ObservableAwait`, but nothing of that name moved in this diff 🚨 That reddens EVERY subsequent PR, not one. Measured: both currently open PRs fail `Public surface (binary compatibility)` on it — #2782 (a test guard plus an allow file) and #2781 (a documentation-only Homebrew change). Neither can reach a public type; both are blocked by main. This is the failure mode the allow file's own rule names and that #2678 -> #2688 already paid for once: an allow entry goes stale FLEET-WIDE the instant its move merges, so it must be deleted in the VERY NEXT change. It was flagged on #2771 before that merge and landed with it anyway, which is exactly how the previous seven stale entries accumulated. The file now carries no live entries — header only, which is the correct state: nothing is currently exempt. Verified: scripts/check-type-forwards.py --self-test -> All 28 self-tests passed scripts/check-type-forwards.py --base <merge-base> -> OK, no unguarded public-type move Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Removes a stale entry from the type-forward allowlist that was causing the binary-compatibility gate to fail on every PR branched after #2771, thereby unblocking CI for subsequent pull requests.
Changes:
- Deleted the outdated
MeshWeaver.Fixture:MeshWeaver.Fixture.ObservableAwaitallow entry fromscripts/type-forwards.allow.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Contributor
Contributor
Contributor
Contributor
Contributor
Contributor
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Main is blocking every PR
scripts/type-forwards.allowstill listsMeshWeaver.Fixture:MeshWeaver.Fixture.ObservableAwait. #2771 has merged, so that move is in main — and the gate compares against the merge base, so relative to any branch cut after #2771 nothing of that name moves:🚨 This reddens every subsequent PR, not one. Both currently open PRs fail
Public surface (binary compatibility)on it:Neither is at fault. They are blocked by main.
This is a known, already-paid-for failure mode
An allow entry goes stale fleet-wide the instant its move merges, so it has to be deleted in the very next change — the lesson of #2678 → #2688, which left seven stale entries behind. It was flagged on #2771 before that merge:
and landed with it anyway. That is precisely how the previous batch accumulated, so this is the next change.
After this, the file carries no live entries
Header only — which is the correct state: nothing is currently exempt, and the next author who needs an exemption writes one with its reason rather than inheriting somebody else's.
Verified
check-type-forwards.py --self-testcheck-type-forwards.py --base <merge-base>OK — no unguarded public-type move🤖 Generated with Claude Code