Skip the external PDS suite when those services are unreachable (wave 29) - #139
Closed
aaronstevenwhite wants to merge 2 commits into
Closed
Skip the external PDS suite when those services are unreachable (wave 29)#139aaronstevenwhite wants to merge 2 commits into
aaronstevenwhite wants to merge 2 commits into
Conversation
…ad of failing main
…wave-29 # Conflicts: # .github/workflows/security.yml # tests/unit/api/handlers/xrpc/trending-paging.test.ts # tests/unit/config/security-scanning.test.ts
Contributor
Author
|
Superseded by #140, which carried waves 16-30 to staging in one piece after I discovered these had been merging into each other's feature branches rather than into staging. The content of this PR is included there and is now on staging; closing to avoid implying it landed separately. |
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.
Summary
Wave 29 closes CI-7: a third-party outage red-lines this repository.
tests/pre-deployment/script-execution.test.tstalks to a real user PDS and the governance PDS, and thePre-Deployment Verificationjob that runs it is a required check on bothstagingandmain. So while bsky.social is unreachable, no pull request can merge — however unrelated the change.This is not hypothetical. The GitHub Actions outage on 2026-08-26 blocked this repository's entire queue for roughly two hours, and the same shape applies to any provider the pre-deployment suite depends on.
The file's own docblock stated the intent — "These tests MUST pass. They do NOT skip" — so this was a deliberate choice, and changing it is a change of policy rather than a bug fix.
The distinction drawn
Unreachable versus wrong:
The skip is deliberately loud. It names the endpoint that failed and prints "This is not a pass: nothing about PDS integration was checked in this run." A skipped run must never be mistakable for a verified one.
Related Issues
Backlog 0.8.0: CI-7. Stacked on #138 (wave 28).
Type of Change
How Has This Been Tested?
9 tests pinning the policy: both endpoints are probed, a 5xx counts as unreachable, the probe is bounded by a timeout so a hang cannot stall the job, the suite is gated on the probe, the skip prints its reason, it states that nothing was verified, and the docblock no longer claims the suite never skips.
I verified
describe.skipIfactually behaves as expected in Vitest 4 with a throwaway probe test — skipping the group while the file still passes — rather than assuming the API does what its name suggests.Full unit suite: 205 files, 4,468 tests passing. Typecheck and lint clean.
Checklist
General
npm run lintpasses)npm test)ATProto Compliance (required for data flow changes)
Breaking Changes
Note for review
This weakens a guarantee, and that is the point of the trade — but it is worth being explicit. A deploy can now proceed having verified nothing about PDS integration, if the PDSes happened to be unreachable when CI ran. The mitigation is that the skip is loud in the job log rather than silent, so the state is discoverable. If that trade is unacceptable, the alternative is to keep the job blocking and accept that third-party availability gates merges; I do not think that is the right default, but it is a legitimate position.