ci: Update Synapse to start alongside index import - #5854
Conversation
The shard waits ~34s in `create realm users` for Synapse to finish booting, then imports nothing from it — the 27s index import that runs just before is entirely independent. Overlap them. This is a different trade from speeding up a step that precedes service start. Measured on #5849, pulling the mirrored images concurrently cut that step from 29s to 13s and the readiness wait grew from 1s to 38s across every shard: the services simply started earlier and the same wall remained. Synapse is on the critical path rather than in front of it — realm-server logs into it during boot — so moving its boot earlier shortens the chain instead of relocating the wait. Backgrounded, because `assert-synapse-running` blocks on Synapse's own healthcheck. It is idempotent, so `test-services:host` finds the container up when it reaches `start:matrix` and only re-registers the Traefik route; the container exists within seconds, long before that step, so they cannot race to create it. Expected: `create realm users` falls toward zero and the readiness wait does not absorb it. If the wait grows instead, the same wall applies here too and the readiness path itself is the only thing left to attack. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3b95f7fe18
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - name: Start Synapse ahead of the index import | ||
| working-directory: packages/matrix | ||
| run: | | ||
| pnpm assert-synapse-running >> /tmp/server.log 2>&1 & |
There was a problem hiding this comment.
When the cached-index step is skipped—on every push/workflow-dispatch run and on PRs that change index behavior—this backgrounded command can overlap almost immediately with test-services:host. I checked mise-tasks/test-services/host:91-93 and packages/realm-server/scripts/start-matrix.sh:10; that path invokes the same assert-synapse-running, whose docker ps/start sequence in packages/matrix/scripts/assert-synapse-running.sh:15-32 has no locking. Both processes can therefore decide boxel-synapse-ci is absent and concurrently stop/start it while rewriting the shared synapse-data-ci configuration, producing intermittent container-name conflicts or a container booted with mismatched generated secrets. Gate the early start on an actual import or add a startup/readiness barrier before the service stack invokes the second starter.
Useful? React with 👍 / 👎.
Host Test Results 1 files 1 suites 1h 52m 21s ⏱️ Results for commit 3b95f7f. |
1 participant
These aren’t interrelated, so might as well happen in parallel.
Claude explanation
The shard waits ~34s in `create realm users` for Synapse to finish booting, then imports nothing from it — the 27s index import that runs just before is entirely independent. Overlap them.This is a different trade from speeding up a step that precedes service start. Measured on #5849, pulling the mirrored images concurrently cut that step from 29s to 13s and the readiness wait grew from 1s to 38s across every shard: the services simply started earlier and the same wall remained. Synapse is on the critical path rather than in front of it — realm-server logs into it during boot — so moving its boot earlier shortens the chain instead of relocating the wait.
Backgrounded, because
assert-synapse-runningblocks on Synapse's own healthcheck. It is idempotent, sotest-services:hostfinds the container up when it reachesstart:matrixand only re-registers the Traefik route; the container exists within seconds, long before that step, so they cannot race to create it.Expected:
create realm usersfalls toward zero and the readiness wait does not absorb it. If the wait grows instead, the same wall applies here too and the readiness path itself is the only thing left to attack.