Two green branches can merge red
Two Desktop branches passed alone, then one merged result failed to compile and another lost a revoke control with five tests.
Two green branches can produce a red merged result. Our Muniment Desktop record caught that gap twice in three days.
One merge failed loudly before a test ran. The next stayed green after it removed the control and tests that could expose the loss.
An older call stopped the merged build
On August 2, one branch changed Projector::push from two arguments to three. A second branch started from an older base and still called the two-argument form.
Each branch passed alone. After both merged, the full Rust core run failed to compile with error E0061 before any test ran.
The repository records no failed CI run for that incident. Its branch gate had answered whether each branch passed against its own base.
Five deleted tests let the loss stay green
On August 4, one branch added a companion revoke control and its tests to the profile popover. Another branch merged from an older base.
That later merge removed the control and five tests:
- Keyboard access.
- Escape cancellation.
- Escape handling by the profile.
- Refresh after a confirmed revoke.
- Retry after a failed revoke.
Both branches were green at merge time. The second loss produced no red because the tests that described the feature no longer existed.
The two failures exposed different signals:
| Stale branch effect | Merged result | Gate signal |
|---|---|---|
| Kept an old function call | Rust error E0061 |
Compilation failed after merge |
| Removed a revoke control and five tests | Feature and coverage disappeared | No test remained to fail |
Strict checks and a merge queue test different sets
GitHub calls a required status check strict when the branch must be up to date with its base before merging. Another target update can force another branch update and build.
A merge queue instead tests a pull request against the latest target branch and changes already in the queue. Authors do not update each branch and wait again before joining the queue.
GitHub is neither a Muniment customer nor an endorser. Its documentation defines these repository controls, while our Desktop record supplies the two incidents.
The diagnosis shipped no repository control
We made no application-code fix in this record. Strict up-to-date checks and a merge queue are repository settings that only the owner controls.
The record does not say that either setting shipped. It does not prove that a merge queue would have caught either incident.
It also measures no build delay, merge delay, application performance, or other result from either setting.
Visitors cannot exercise Muniment Desktop through a public install or authentication surface yet.
This evidence comes from our Muniment Desktop note pinned to commit a6655f14f74b6aaa1a1c.
A green branch records one tested state. Make the merge gate test the state that will enter the target branch.
Sources
- GitHub Docs: About protected branches docs.github.com