You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We purge files from the CDN on deploy to prevent stale maven-metadata.xml files (and their checksum files). But we do this in a future to not delay the deploy, and there is no error handling around that. So if it fails we don't know about it and there is stale data in the cache.
We should:
track failures
add retry logic
The text was updated successfully, but these errors were encountered:
This will at least allow us to see when they happen and address
manually. We'll do later work to add retries if we are seeing failures.
Related to #831.
submit to in memory job queue, a background thread to purge the files. We can do error handling and retry, we can have more fine-grained control, like de-duplication / rate limit / throttle in this way. would need some refactoring.
add retry logic in the future. Get the job done, but don't have much control.
using resilience4j? less home baked retry logic, but we have one more dependency and at least two more components.
I think it would be fine to do a simple retry in the future (option 2). I've seen no Sentry reports of purge failures since adding reporting, so I think failures here are rare.
A simple backoff/retry strategy would work. I think we should still report each failure to sentry even when we retry.
We purge files from the CDN on deploy to prevent stale
maven-metadata.xml
files (and their checksum files). But we do this in afuture
to not delay the deploy, and there is no error handling around that. So if it fails we don't know about it and there is stale data in the cache.We should:
The text was updated successfully, but these errors were encountered: