Retry SSI jobs on scenario timeouts and on the pulumi "short write" error - #7608
Merged
Conversation
When Pulumi fails to provision a VM, `_handle_provision_error` matches the error
text against `aws_infra_exceptions.json`. A known message tears the stack down and
exits 3, so GitLab retries the job (`retry:exit_codes`). Anything else was stashed
on the VM object and returned normally, resurfacing later as an assert inside the
tests ("There are previous errors in the virtual machine provisioning steps") —
pytest then exits 1, which reads as a test failure and is never retried.
A single transient infra flake whose message happened not to be in that list would
therefore fail the SSI stage for good and block the release pipeline, needing a
manual retry every time.
Exit 3 on unknown provisioning failures too. A provisioning failure is not a test
result: the tests never ran. Teardown is unchanged — `pytest.exit` unwinds through
`pytest_sessionstart`, which calls `close_targets()` to download the VM logs and
destroy the stack, so each of the 3 attempts starts clean and the logs are still
collected. The Datadog event is unchanged, so `result:fail` now measures exactly
the unknown-provisioning-failure rate, and `aws_infra_exceptions.json` no longer
gates whether a job is retried.
Also add 124 to the onboarding job's retry exit codes, matching the docker SSI job
(`run.sh` is wrapped in `timeout 3000`).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
|
🎉 All green!🧪 All tests passed 🔗 Commit SHA: 6c2dcc0 | Docs | View more details | Give us feedback! |
cbeauchesne
reviewed
Aug 28, 2026
cbeauchesne
left a comment
cbeauchesne
left a comment
Collaborator
There was a problem hiding this comment.
AGTM, but @robertomonteromiguel will have a better educated opinion.
robertomonteromiguel
requested changes
Aug 28, 2026
robertomonteromiguel
left a comment
robertomonteromiguel
left a comment
Collaborator
There was a problem hiding this comment.
agree to include the 124 exit code for the retries (timeout), but not agree to retry the job in the provision failure is unknown
Per review: unknown provisioning failures should keep failing the job, so revert aws_provider.py to main. The failure that actually blocked the release pipeline was `error: short write: running ...` on the vm_logs step. That is pulumi-command losing the SSH transport while streaming output, not the remote script failing -- the VM was fully provisioned and vm_logs is the last, purely diagnostic step. Adding it to aws_infra_exceptions.json routes it through the existing known-infra-error path. 🤖 Written with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ddmatan
changed the title
robertomonteromiguel
approved these changes
Aug 28, 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
4 participants
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.
Motivation
Two transient provisioning/CI failures fail an SSI job for good today, and a single one of them blocks the whole release pipeline.
1. Scenario hangs → exit 124.
run.shis wrapped intimeout 3000, so a hung scenario exits 124. That code was not inretry:exit_codes, so the job just died.2.
error: short write: running .... This is what actually blocked the pipeline in the release thread:That's pulumi-command losing the SSH transport while streaming a remote command's output — not the remote script failing. Two things worth knowing:
curlinside that script returnedHTTP/1.1 200 OK, so the app was up and the VM was fully provisioned;vm_logsis the last provisioning step (virtual_machine_provider.py) and it's purely diagnostic — it copies/var/logout for the artifacts.So a dropped SSH write while copying logs failed the stack → failed provisioning → every test asserted on
provision_install_error→ job failed → release blocked.Changes
124toretry:exit_codesin.gitlab/ssi_gitlab-ci.yml"pulumi_command_short_write": "error: short write: running"toaws_infra_exceptions.jsonThe second one routes the error through the existing known-infra-error path: destroy the stack, send a
result:retryevent,pytest.exit(returncode=3)→ the job is retried. No new retry mechanism.Note on the previous version of this PR
The first version also made unknown provisioning failures exit 3 so they'd be retried. Reverted per review — unknown failures keep failing the job, as before. Only errors we've explicitly identified get retried.
Why not make
vm_logsnon-fatal insteadPulumi has no per-resource "tolerate failure" option, so that would mean moving the log extraction out of the Pulumi graph entirely. Bigger change than this is worth; happy to do it separately if you'd prefer.
🤖 Written with Claude Code