Skip to content

feat: data-links - recover from expired signing credentials during large data-link uploads - #652

Draft
georgi-seqera wants to merge 1 commit into
masterfrom
gh/feat/upload-refresh-token
Draft

feat: data-links - recover from expired signing credentials during large data-link uploads#652
georgi-seqera wants to merge 1 commit into
masterfrom
gh/feat/upload-refresh-token

Conversation

@georgi-seqera

Copy link
Copy Markdown
Contributor

Summary

Recover from expired signing credentials during large data-link uploads

Why

tw data-links upload fails partway through large uploads with HTTP 400 ExpiredToken (e.g. a 108 GiB upload died at ~75% after ~60 minutes). The presigned URLs the CLI receives at the start of a multipart upload are signed with temporary credentials that expire after ~1 hour, and the CLI had no way to recover — it uploaded parts strictly sequentially, with no retry and no ability to obtain fresh URLs, so any upload outliving the credential lifetime failed outright.

This is the client half of the fix; it pairs with the new Platform refresh endpoint introduced in 26.2.0 (API version 1.192.0).

How

The CLI now detects an expired-credentials error mid-upload, asks Platform to re-sign the URLs for the parts it still needs, and retries them — so a long-running upload transparently continues instead of failing.

Alongside that, the upload path gains general resilience it was missing:

  • Transient-error and network retry with exponential backoff for temporary failures (5xx, throttling, dropped connections), independent of the credential-refresh path.
  • Retry-safe progress reporting, so retried parts don't double-count against the progress bar.
  • Graceful degradation against older Platforms: if the refresh endpoint isn't available (404), the CLI stops with a clear, actionable message rather than a confusing low-level error.

Behavior differs per provider, matching what each backend can actually support:

Provider Transient/network retry Refresh on credential expiry
AWS S3 / Seqera Compute managed storage
Azure ✗ (expiry is terminal)
Google Cloud Storage ✗ (uses a long-lived resumable session)

Consuming the refresh endpoint requires a regenerated SDK, so this PR also bumps the Tower Java SDK version.

What it looks like

No new flags or usage changes — the same command now survives credential expiry:

$ tw data-links upload -w my-org/my-ws -n my-bucket -c my-creds ./sample.cram
  Uploading sample.cram [==============>          ] 61%
  # ~1h in, signing credentials expire; the CLI refreshes URLs and continues
  Uploading sample.cram [========================] 100%
  Uploaded 1 file to my-bucket

Against a Platform too old to support refresh, it fails fast with a clear reason instead of a raw ExpiredToken:

$ tw data-links upload -w my-org/my-ws -n my-bucket -c my-creds ./sample.cram
  ERROR: Token refresh is not supported for this Platform version.

Scope

  • CLI + SDK version bump only (paired with the Platform backend PR).
  • No changes to command syntax or output format.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant