Dashboard keeps “Uploading 1 file” after failure instead of showing “Error”

AI authorship and provenance

This report was generated by GPT-6 Astra, an AI assistant, based on a real-world regression found while upgrading an application from Uppy 3 to Uppy 6. The report distinguishes browser observations from source analysis. The reproduction contains only public Uppy APIs and synthetic data; no application-specific implementation, endpoints, credentials or data are shared.

Summary

When a single upload fails, Dashboard's top heading remains “Uploading 1 file” even though the upload has settled as failed and the footer shows “Upload failed”. This was observed with a real HTTP 422 server-side validation response and independently reproduced without a backend using Uppy lifecycle events.

The underlying file error and footer Retry control are present. This report concerns the inconsistent heading.

Link to runnable example

https://jsfiddle.net/tagliala/y917v0dg/1/

The example is a single HTML document using version-pinned, prebuilt uppy bundles and CSS from jsDelivr. Each version runs in its own iframe. A synthetic uploader fails its first attempt and succeeds on retry. No upload request, account, selected file, framework or build step is needed.

Steps to reproduce

1. Open the fiddle. The comparison runs automatically on load.
2. Select Heading: exact prerelease boundary from the Compare dropdown. Changing the selection reruns the comparison automatically. The Run / reset comparison button can also force a reset.
3. Wait for the synthetic uploads to fail and for the JSON results to appear.
4. Compare the top headings:
   • [email protected]: Error.
   • [email protected]: Uploading 1 file.
5. Enable Emit progress before failing. The heading difference remains.
6. Select Heading: stable release boundary to compare the 3.x line with stable 4.0.0. Select All release checkpoints to include 6.0.1.

The JSON is sampled after allowing the UI to settle. It reports failed: true and complete: false in both good and bad versions, alongside the heading.

Expected behavior

Once the only upload has failed, the heading should display Error, consistent with the error state and footer. A partially failed batch with other files still uploading should retain the appropriate uploading state.

Actual behavior

The heading remains Uploading 1 file in the affected releases. It is still incorrect after completion of the failed attempt, rather than only during an intermediate render.

In the real HTTP validation test:

Observation	Result
HTTP response	422
Progress	100%
File error	Present
Top heading	Uploading 1 file
Individual retry icon	Present
Footer retry control	Present

The exact mismatching-file validation scenario was not tested. The real-world observation above is a server-side validation failure, not a claim about every possible HTTP 422 response.

Confirmed version boundary

The umbrella package uppy and its component packages use different version numbers. Component versions below were read from the running prebuilt bundles.

uppy bundle	@uppy/core	@uppy/dashboard	Failed-upload heading
3.27.2	3.13.1	3.9.1	Error
4.0.0-beta.9	4.0.0-beta.8	4.0.0-beta.8	Error
4.0.0-beta.10	4.0.0-beta.9	4.0.0-beta.9	Uploading 1 file
4.0.0	4.0.0	4.0.0	Uploading 1 file
6.0.1	6.0.1	6.0.0	Uploading 1 file

• First affected prerelease: Dashboard 4.0.0-beta.9, published 2024-06-04, included in uppy 4.0.0-beta.10.
• First affected stable release: Dashboard 4.0.0 / uppy 4.0.0, published 2024-07-10.

Screenshot

Source analysis

@uppy/dashboard: remove unused component props — PR #5213, commit dbfb93f133, removed isAllErrored from both:

1. The destructuring of uppy.getObjectOfFilesPerState() in Dashboard's render.
2. The props forwarded to the Dashboard UI.

However, PickerPanelTopBar still consumes isAllErrored and only selects its error heading when that value is truthy. Otherwise, a file with uploadStarted set and uploadComplete false selects the uploading heading.

Relevant source at the checked main revision:

• Dashboard.tsx
• PickerPanelTopBar.tsx

Candidate fix for maintainers to assess: restore forwarding of isAllErrored, with tests for one failed file, all files failed, and a mixed batch that still has active uploads. This candidate has not been patched or validated by this report.

Unreleased main and existing reports

The canonical repository transloadit/uppy was checked on 2026-09-13 at main commit 49199f24c2a57a88aada504dabb17cc5dcf19afe. Dashboard.tsx and PickerPanelTopBar.tsx have identical Git blob hashes to Dashboard 6.0.0; Uppy.ts is also identical to Core 6.0.1. No unreleased fix was found in these controlling paths. Main was source-reviewed, not browser-built.

Searches for isAllErrored, error headings/titles, and related uploading/error terms found no matching current report or corrective PR. This does not establish whether maintainers are already aware through another channel.

Verification and limitations

• Chromium 153.0.8010.12, macOS arm64, driven by Playwright 1.63.0.
• The human reporter also manually checked the reproduction in Firefox 155.0.1 (aarch64) and Safari 26.6.2 (21624.5.1.11.3). These are reporter-provided manual checks, not additional AI-run automation.
• Eight released bundles were exercised with and without progress: 16 version/progress combinations. Retry recovery succeeded in all 16 using an available retry control.
• The single HTML reproduction uses addUploader, upload-start, upload-progress, upload-error and upload-success; it does not override internal state or render a replacement Dashboard.
• The HTTP 422 observation came from the separate real upload integration; the public demo isolates the UI from transport behavior.
• Automated verification used the local standalone HTML. The reporter published the linked fiddle and supplied the Firefox/Safari checks above. The AI did not independently rerun those manual checks or the hosted result. The 16-case automated matrix is specific to Chromium.

Related report

Separate conditional missing-retry-control regression. The two reports share the same standalone reproduction but have different release boundaries and evidence.