Problem
RabbitMQ has two required open addon changes that must ship and be validated together, but their heads diverge:
Testing either head alone does not produce a complete candidate identity. Existing runtime evidence is exact-head scoped and cannot be transferred to a new combined SHA.
Test scenario that exposed the gap
The candidate-freeze audit enumerated every open, non-draft RabbitMQ addon PR before launching the next acceptance cycle. It found that PR #3113 and PR #3014 are both required, neither contains the other, and the approved runner therefore has no single addon SHA to install for account-focused followed by fresh full-suite validation.
Reproducibility
Reproducible on the current repository state.
How to reproduce
git fetch origin pull/3113/head:pr-3113 pull/3014/head:pr-3014
git merge-base --is-ancestor pr-3113 pr-3014; echo $?
git merge-base --is-ancestor pr-3014 pr-3113; echo $?
Both ancestry checks return non-zero. The heads are 0c027e5d3a73c78594ae51430241b04d399ebc05 and 73598b7d12fcd5d7923ac2ff7057077acc6cc8fc.
Expected result
Create a development base rebased on current main, integrate the two PR #3014 commits through a child PR, independently review the combined tree, and return one exact integration SHA for account-focused and fresh full-suite runtime validation. Old-head evidence remains attached only to its original SHA.
Problem
RabbitMQ has two required open addon changes that must ship and be validated together, but their heads diverge:
Testing either head alone does not produce a complete candidate identity. Existing runtime evidence is exact-head scoped and cannot be transferred to a new combined SHA.
Test scenario that exposed the gap
The candidate-freeze audit enumerated every open, non-draft RabbitMQ addon PR before launching the next acceptance cycle. It found that PR #3113 and PR #3014 are both required, neither contains the other, and the approved runner therefore has no single addon SHA to install for account-focused followed by fresh full-suite validation.
Reproducibility
Reproducible on the current repository state.
How to reproduce
Both ancestry checks return non-zero. The heads are
0c027e5d3a73c78594ae51430241b04d399ebc05and73598b7d12fcd5d7923ac2ff7057077acc6cc8fc.Expected result
Create a development base rebased on current
main, integrate the two PR #3014 commits through a child PR, independently review the combined tree, and return one exact integration SHA for account-focused and fresh full-suite runtime validation. Old-head evidence remains attached only to its original SHA.