PAYMENTS-11727 Proof: the fork delivery specs fail on 0.8.3 as released - #43
Draft
WillemHoman wants to merge 5 commits into
Draft
PAYMENTS-11727 Proof: the fork delivery specs fail on 0.8.3 as released#43WillemHoman wants to merge 5 commits into
WillemHoman wants to merge 5 commits into
Conversation
added 5 commits
August 6, 2026 19:53
… overhead across Resque forks
This was referenced Aug 7, 2026
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.
Jira: PAYMENTS-11727
Not for merge. This exists to demonstrate that the regression specs added in
#45 would have caught the metric loss that 0.8.3 shipped.
What? Why?
mainis 0.8.3, the release that dropped webhook metrics in bigpay. This branch adds nothing but the specs from #45,cherry-picked, and the CI job that runs them.
The result is the completeness property failing and the overhead property passing, which is the signature of that
incident: job time stayed flat while the observations silently went nowhere.
Zero of 100, not a partial loss. Production saw roughly 8% survive rather than 0% because a real webhook job does a
little work after its push and sometimes wins the race; the probe job pushes as its final statement, so it never does.
Commits
209dd85resqueandsinatra >= 4.0dev dependencies (cherry-pick)48d02571db4208db5261d3505a25The adaptation is the only deviation from #45. The spec's setup calls
client.reset_after_fork!to make the runindependent of spec ordering, and that method is part of the fix, so it does not exist here. Replaced with a direct
@queue.clear, which is the only part of it the setup needs. Nothing in either assertion changed.How was it tested?
ruby-3_4-rspec_fork_integrationis expected to be red on this branch. That is the point of it.See also #44, which does the same for the PAYMENTS-11567
latency regression.