During an automated source upload for the Python documentation, a Transifex resource ended up with zero strings, although the local POT file was valid and the CLI reported Done after retrying an HTTP 502 response.
This has happened intermittently. We do not yet have a reliable reproducer or know whether the underlying problem is in the CLI, the API, or their interaction.
What happened
Our CI uploads source POT files using tx push -f -s. On September 13, 2026, the upload of python-313.c-api--stable encountered this sequence (timestamps and resource prefixes omitted here):
Uploading file
Response error code 502, retry after 10
Uploading file
Done
Afterward, the resource on Transifex contained zero strings, and subsequently downloaded PO files were broken. The local source POT file was correct.
A manual forced reupload restored the resource:
tx push -f -s python-313.c-api--stable
The incident, recovery details, and full CI log attachment are available in python-docs-translations/transifex-automations#246 (python-docs-translations/transifex-automations#246 (comment)).
Expected behavior
A retry should upload the complete source file. A transient upload failure should preserve the existing resource contents.
If the upload cannot complete successfully, the CLI should report an error and return a nonzero exit status.
Actual behavior
The CLI reported completion after retrying, but the remote resource was empty. Our automation did not flag the upload as failed.
Impact
This silently removes all source strings from the affected resource and propagates broken PO files to downstream translation repositories. It requires manual detection and reuploading the source.
Related issues
Neither appears to cover a source upload leaving the remote resource empty after a retry.
Could you investigate whether the retry resends the complete upload body and whether a failed upload can replace the existing resource contents with an empty result?
During an automated source upload for the Python documentation, a Transifex resource ended up with zero strings, although the local POT file was valid and the CLI reported
Doneafter retrying an HTTP 502 response.This has happened intermittently. We do not yet have a reliable reproducer or know whether the underlying problem is in the CLI, the API, or their interaction.
What happened
Our CI uploads source POT files using
tx push -f -s. On September 13, 2026, the upload ofpython-313.c-api--stableencountered this sequence (timestamps and resource prefixes omitted here):Afterward, the resource on Transifex contained zero strings, and subsequently downloaded PO files were broken. The local source POT file was correct.
A manual forced reupload restored the resource:
The incident, recovery details, and full CI log attachment are available in python-docs-translations/transifex-automations#246 (python-docs-translations/transifex-automations#246 (comment)).
Expected behavior
A retry should upload the complete source file. A transient upload failure should preserve the existing resource contents.
If the upload cannot complete successfully, the CLI should report an error and return a nonzero exit status.
Actual behavior
The CLI reported completion after retrying, but the remote resource was empty. Our automation did not flag the upload as failed.
Impact
This silently removes all source strings from the affected resource and propagates broken PO files to downstream translation repositories. It requires manual detection and reuploading the source.
Related issues
.stringsdictfiles #84 concerned a gateway error being saved as downloaded file contents while the CLI reported success; it was reported fixed in v1.3.1.Neither appears to cover a source upload leaving the remote resource empty after a retry.
Could you investigate whether the retry resends the complete upload body and whether a failed upload can replace the existing resource contents with an empty result?