Skip to content

fix(cli): explain bundle upload timeouts instead of raw AbortError - #2896

Draft
posthog-eu[bot] wants to merge 1 commit into
mainfrom
posthog-self-driving/fixcli-report-bundle-upload-timeouts-d9f80f
Draft

fix(cli): explain bundle upload timeouts instead of raw AbortError#2896
posthog-eu[bot] wants to merge 1 commit into
mainfrom
posthog-self-driving/fixcli-report-bundle-upload-timeouts-d9f80f

Conversation

@posthog-eu

@posthog-eu posthog-eu Bot commented Aug 6, 2026

Copy link
Copy Markdown

Summary

  • Who's hurt: users whose bundle upload trips the CLI's hidden 120s wall-clock timeout on the standard (non-TUS) path see only This operation was aborted — no sign a timeout fired, no pointer to a workaround — so a self-service retry becomes a support ticket.
  • Root cause: the PUT is wrapped in an AbortController armed with setTimeout(..., UPLOAD_TIMEOUT) (120s). Nothing distinguished the abort from any other failure, so the raw AbortError was printed and rethrown verbatim.
  • Duplicate issues: with no stack frames and a version-scoped fingerprint, every CLI release reopened the same error as a brand-new inbox item.

Changes

  • Detect the abort at the PUT site and throw a typed BundleUploadTimeoutError whose message names the elapsed budget and points at --tus (resumable, chunked, retries) and --timeout (raise the limit).
  • Print that message as-is in the catch block, without the generic Cannot upload bundle prefix.
  • A stable, typed error name/message collapses the per-version duplicates into a single error-tracking issue.
  • Fix the misleading verbose Retry attempts: 5 line — the standard path has no retries (only the TUS path does).

Test plan

  • bun run test:upload — extended to assert the timeout message names the 120s budget, says timed out, and mentions both --tus and --timeout, and that a custom --timeout is reflected in the message.
  • bun run typecheck and bun run lint pass.

Screenshots

N/A — CLI error-message text change; before/after covered by the added test assertions.

Checklist

  • My code follows the code style of this project and passes
    bun run lint:backend && bun run lint.
  • My change requires a change to the documentation.
  • I have updated the documentation
    accordingly.
  • My change has adequate E2E test coverage.
  • I have tested my code manually, and I have provided steps how to reproduce
    my tests

Created with PostHog Desktop from this inbox report.


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.

Review in cubic

The standard (non-TUS) upload arms an AbortController with a 120s wall-clock
timeout. When it fired, the raw "This operation was aborted" AbortError was
printed and rethrown verbatim, giving no hint that a timeout occurred or how to
work around it, and landing in error tracking as a fresh per-version duplicate.

- Detect the abort at the PUT site and throw a typed BundleUploadTimeoutError
  whose message names the elapsed budget and points at --tus and --timeout.
- Print that message as-is in the catch block (no generic prefix); the stable
  name/message collapses the per-CLI-version duplicate issues into one.
- Fix the misleading verbose "Retry attempts: 5" line — the standard path does
  not retry (only TUS does).

Generated-By: PostHog Code
Task-Id: 4c908637-5113-4f9e-bef6-395756b5f5f9
@codspeed-hq

codspeed-hq Bot commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Merging this PR will not alter performance

✅ 43 untouched benchmarks
⏩ 2 skipped benchmarks1


Comparing posthog-self-driving/fixcli-report-bundle-upload-timeouts-d9f80f (8d819a3) with main (60a641e)2

Open in CodSpeed

Footnotes

  1. 2 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports.

  2. No successful run was found on main (8b32a45) during the generation of this report, so 60a641e was used instead as the comparison base. There might be some changes unrelated to this pull request in this report.

@sonarqubecloud

sonarqubecloud Bot commented Aug 6, 2026

Copy link
Copy Markdown

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.

0 participants