fix(CLI): cache ignored when using --parallel with phrase pull#1085
Conversation
Restore ctx.Err() check in PullParallel goroutines to respect context cancellation after first failure. Make copyToDestination fail explicitly on nil file instead of silently creating empty files. Remove dead 304 check after rate-limit retry. Simplify pull dispatch by replacing pullFn type with if/else. Add mutex to Save() and json:"-" to mu field for defensive thread safety.
|
jablan Do you think you can have a look this week? |
|
Thibaut Etienne (@tetienne) We had de change our priorities a bit. We will now pick it up again. |
There was a problem hiding this comment.
ℹ️ Cache key changes for plain LocaleDownloadOpts fields (plain fields were previously omitted from the cache key)
Correctness fix, but it means any existing cache files with non-zero plain fields in LocaleDownloadOpts will produce different keys after upgrade. Not a big issue though, as this feature is new anyways.
| if response != nil && response.StatusCode == 304 { | ||
| return nil, response, nil | ||
| } |
There was a problem hiding this comment.
A 304 is intercepted, the caller then re-checks response.StatusCode == 304. It works, but the responsibility boundary is blurry.
3 participants
When splitting the work between #1066 (--cache) and #1067 (--parallel), I forgot to thread the cache through the parallel code path. As a result,
--cache --parallelsilently ignored the cache: no conditional headers were sent, no ETags were stored, and every run re-downloaded all locale files.Tested against a production project with 204 locale files:
Test plan
go buildcompilesphrase pull --cache --parallelsecond run returns 304 for all filesphrase pull --parallelwithout--cachebehaves identically to beforephrase pull --cachewithout--parallelunaffected