test(comms): deepen supervisor orchestration coverage (RIG-3533) - #1114
Merged
Conversation
The orchestration file held one case: a supervisor assigning to two workers. Three contracts around it were unasserted, so a regression in any of them would have landed green. Per-topic thread isolation posts four workers' assignments interleaved across topics rather than grouped, because grouped posts read back correctly even when topic scoping is broken. Upward reports pin the author to the worker, not the supervisor or the owner. The membership-scoped audit asserts an outsider gets exactly zero hits, which is the no-existence-oracle contract rather than a cosmetic count. Each case was verified by mutating production and watching it fail: drop the ListMessages topic filter, credit a different valid channel member as author, and widen the search membership join past the caller. The audit case is mutated in the leak direction specifically, since a mutation that returns nothing exercises the positive assertion instead of the negative. The record's fourth case, reparent reflected in coordination membership, is deliberately omitted: TestReparentInEmitsMembershipMove already drives the identical setup and the same both-halves membership assertions, and also asserts the removed_account_ids event, so it is strictly stronger. Co-authored-by: Matt Wilkinson <matt@rigel.build>
|
😎 This pull request was merged. |
rigel-mintaka
marked this pull request as ready for review
September 11, 2026 20:24
|
Compass engineering docs preview: https://compass-comms-rig3533-orches.compass-eng-docs.pages.dev Deployed from |
rigel-mintaka
added this pull request to stack #1124
September 11, 2026 23:43
This was referenced Sep 12, 2026
Merged
mattwilkinsonn
approved these changes
Sep 12, 2026
|
This pull request was merged into |
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.
This PR is part of a stack containing 4 PRs:
mainThe orchestration file held one case: a supervisor assigning to two
workers. Three contracts around it were unasserted, so a regression in any
of them would have landed green.
Per-topic thread isolation posts four workers' assignments interleaved
across topics rather than grouped, because grouped posts read back
correctly even when topic scoping is broken. Upward reports pin the author
to the worker, not the supervisor or the owner. The membership-scoped audit
asserts an outsider gets exactly zero hits, which is the no-existence-oracle
contract rather than a cosmetic count.
Each case was verified by mutating production and watching it fail: drop
the ListMessages topic filter, credit a different valid channel member as
author, and widen the search membership join past the caller. The audit
case is mutated in the leak direction specifically, since a mutation that
returns nothing exercises the positive assertion instead of the negative.
The record's fourth case, reparent reflected in coordination membership, is
deliberately omitted: TestReparentInEmitsMembershipMove already drives the
identical setup and the same both-halves membership assertions, and also
asserts the removed_account_ids event, so it is strictly stronger.
Co-authored-by: Matt Wilkinson matt@rigel.build