Setting this as self-assigned and waiting until I hear back from the maintainers, or a few days pass, whichever comes first. Fingers crossed we don't need to fork to implement at the level I'm looking at (though we could also wrap in retries at a higher level, albeit with a performance decrease when things fail).
This is low-severity as getting a 503 from CloudFront is rare.
🛠️ To fix
We'll want to either add retries at the fetcher level on goval-dictionary (preferably without maintaining our own fork) or retry failures at the entire-command level inside the workflow. The former is cleaner but probably more work. Deferring estimation until I get confirmation of whether upstream wants this fix, as they tend to be pretty responsive.
💥 Actual behavior
A single 503 breaks
goval-dictionary
assisted vuln pulls, which fails thevulnerabilities
release process. . Credit @mostlikelee for spotting the failure.🧑💻 Steps to reproduce
goval-dictionary
in thevulnerabilities
repo🕯️ More info
Checking to see whether the upstream dependency would be willing to accept, or add, retries to their fetcher method: https://github.com/vulsio/goval-dictionary/issues/415
Setting this as self-assigned and waiting until I hear back from the maintainers, or a few days pass, whichever comes first. Fingers crossed we don't need to fork to implement at the level I'm looking at (though we could also wrap in retries at a higher level, albeit with a performance decrease when things fail).
This is low-severity as getting a 503 from CloudFront is rare.
🛠️ To fix
We'll want to either add retries at the fetcher level on
goval-dictionary
(preferably without maintaining our own fork) or retry failures at the entire-command level inside the workflow. The former is cleaner but probably more work. Deferring estimation until I get confirmation of whether upstream wants this fix, as they tend to be pretty responsive.