Open martinbonnin opened 1 year ago
Actually, we've added the the SEGMENT_DOWNLOAD_TIMEOUT_MINS=3 to our env, but cache restore still gets stuck and timeouts after 10 minutes (due to step timeout). So the question is, whether this env variable works as expected...
See this for example: https://github.com/project-chip/connectedhomeip/actions/runs/5057625376/jobs/9076622982
Or maybe this env variable works in a different way than it's described... Our cache blob do not exceeds 2GB, so as far as I understand, it's downloaded in one segment. So, in case of SEGMENT_DOWNLOAD_TIMEOUT_MINS=3
, cache step should run no more than 3 minutes (+ some jiffies).
This issue is stale because it has been open for 200 days with no activity. Leave a comment to avoid closing this issue in 5 days.
This is still valid.
This issue is stale because it has been open for 200 days with no activity. Leave a comment to avoid closing this issue in 5 days.
bump
We are currently affected by cache read timeouts. The pattern is similar to https://github.com/actions/cache/issues/1141: cache download starts normally and then download stops completely.
There is a SEGMENT_DOWNLOAD_TIMEOUT_MINS environment variable but it only affects a full segment (1 or 2 GB).
Would it be possible to have more granular control over the timeout? Maybe something like:
SEGMENT_CONNECT_TIMEOUT_SECS
: Timeout if it takes more than X seconds to establish the connection to the remote cache.SEGMENT_REAT_TIMEOUT_SECS
: Timeout if there is more than X seconds without a single byte being read on the wire.SEGMENT_DOWNLOAD_TIMEOUT_MINS
: keep current behaviour. Timeout if it takes more than X minutes to download a segment.This way, we don't have to wait 10min if a relatively small entry times out