Skip to content

finding: storage.resumeUpload ignores progress.status, so resuming an expired session surfaces as a 410 on the first chunk instead of a clean early exit #7870

Description

@huangyiirene

Observation

Since #7667 (PR #7844) a chunked upload session past its own expires_at is durably stamped expired, GET .../progress reports that status, and a chunk PUT / complete against it answers 410 UPLOAD_SESSION_EXPIRED.

packages/client's storage.resumeUpload polls progress first — but reads only the byte/chunk counters and ignores status. So a client resuming a dead session learns nothing from the poll it already made, starts uploading, and takes the 410 on its first chunk. Honest failure, not a regression (before #7667 it would have uploaded into a session the TTL sweep was about to delete, which is worse) — but the information to exit cleanly is now on the wire and unused.

Where

packages/client — the resumeUpload path that calls GET /api/v1/storage/upload/chunked/:uploadId/progress. Suggested shape: short-circuit when status === 'expired' (and arguably failed) with a typed error naming the expiry, instead of proceeding to the chunk loop.

Why a finding, not a queue card

No user report; the behaviour is correct-but-clumsy rather than wrong, and the fix is a client-side UX judgment (which statuses short-circuit, what the caller sees) rather than a mechanical gap. Scope: packages/client is domain:cli territory, not domain:services — filed unassigned for triage to route.

Refs

Metadata

Metadata

Assignees

Labels

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions