[WC-3460]: FileUploader pre-release QA & decision review

[yordan-st]

Pull request type

Bug fix (non-breaking change which fixes an issue)

Description

Pre-release QA and decision review for file-uploader-web covering changes introduced by WC-3361 (upload queue, concurrent upload limit, total file limit feedback, retry for over-limit files, list ordering) and WC-3363 (dismiss for invalid-format rejections, yellow warning lifecycle).

Two bugs found and fixed:

• sortedFiles was only pushing validationError entries to the end of the list; rejected (over-limit) files were sorting alongside successful uploads. Fixed to push both validationError and rejected below all other entries.
• Invalid-format drops produced per-entry error messages but no yellow warning banner on the dropzone. Fixed by wiring the new hasValidationErrors computed into FileUploaderRoot warningMessage logic — banner appears when validationError files are present and clears when all are dismissed.

What should be covered while testing?

File limit feedback

• Set maxFilesPerUpload = 3. Drop 3 files → dropzone greys out + "Maximum file count of 3 reached." message appears
• While at limit, remove one uploaded file → dropzone re-enables, message disappears
• Set maxFilesPerUpload = 0 or leave empty → dropzone never disables, no message ever shown

Upload queue

• Set maxFilesPerBatch = 2. Drop 5 files → exactly 2 show "Uploading…", remaining 3 show "Waiting…" with no progress bar
• One upload completes → next queued file auto-starts (now 2 uploading again)
• Leave maxFilesPerBatch empty → all dropped files start uploading simultaneously
• Simulate upload error (network off) → that slot frees up, next queued file starts automatically

Retry for over-limit rejections

• Set maxFilesPerUpload = 2. Drop 4 files → 2 upload, 2 appear as rejected with retry button greyed out
• Remove one uploaded file → retry button on one rejected file becomes enabled
• Click retry → that file starts uploading; remaining rejected files still show greyed retry
• Upload failure does NOT auto-promote remaining queued or rejected files

Dismiss for invalid-format rejections

• Configure allowed formats (e.g. PDF only). Drop an unsupported file → yellow warning appears on dropzone + rejected entry with ✕ button
• Click ✕ on the entry → entry removed, yellow warning clears
• Drop 2 unsupported files → dismiss one → yellow warning still visible; dismiss the second → warning clears
• Drop an invalid file, then drop a valid file → previous invalid entry clears immediately, yellow warning clears on drop

List ordering

• Mixed session (some uploaded, some rejected/invalid) → successful files always render above rejected and invalid entries

Regression checks

• Set readOnlyMode = true → dropzone is not rendered, no errors
• Switch uploadMode to images → queue, limit, and dismiss behavior works identically to files mode
• Upload without any limits configured → no regressions in standard upload flow

[github-actions]

AI Code Review

⚠️ Approved with suggestions — low-severity items only, safe to merge

---

What was reviewed

File	Change
packages/pluggableWidgets/file-uploader-web/src/components/FileUploaderRoot.tsx	Wires hasValidationErrors into warningMessage chain
packages/pluggableWidgets/file-uploader-web/src/stores/FileUploaderStore.ts	Adds hasValidationErrors computed; fixes sortedFiles to also push rejected to the end
packages/pluggableWidgets/file-uploader-web/src/stores/__tests__/FileUploaderStore.spec.ts	Renames one test description for clarity

Skipped (out of scope): dist/, pnpm-lock.yaml

CI checks could not be fetched in this environment — no failures observed locally.

---

Findings

⚠️ Low — sortedFiles fix has no test for rejected sorting

File: packages/pluggableWidgets/file-uploader-web/src/stores/__tests__/FileUploaderStore.spec.ts lines 726–756

Note: The existing sortedFiles describe block only asserts that validationError files sort to the end. The PR's primary sortedFiles fix (including rejected in the sort-to-end group) has no direct test coverage. Adding a case would protect this regression:

test("rejected files sort to the end alongside validationError files", () => {
    const store = buildStore({
        maxFilesPerUpload: dynamic(new Big(2)),
        maxFilesPerBatch: unavailableDynamic()
    });
    store.objectCreationHelper.request = jest.fn().mockReturnValue(new Promise(() => {}));

    // 2 uploading + 1 rejected
    store.processDrop([makeFile("a.txt"), makeFile("b.txt"), makeFile("c.txt")], []);

    const sorted = store.sortedFiles;
    expect(sorted[sorted.length - 1].fileStatus).toBe("rejected");
    const nonRejected = sorted.filter(f => f.fileStatus !== "rejected");
    expect(nonRejected.every(f => f.fileStatus !== "validationError" && f.fileStatus !== "rejected")).toBe(true);
});

---

⚠️ Low — No direct test for hasValidationErrors computed

File: packages/pluggableWidgets/file-uploader-web/src/stores/__tests__/FileUploaderStore.spec.ts

Note: hasValidationErrors is the new computed that drives the yellow warning banner. It is exercised indirectly through integration paths, but there is no unit test for the three cases: returns true with at least one validationError file, returns false with only rejected/done files, and returns false when all validationError files are dismissed. A targeted describe block would cost very little and prevent silent breakage if the status string changes.

---

Positives

• Priority order in warningMessage is correct: isFileUploadLimitReached and createActionFailed remain higher priority; hasValidationErrors only fires when neither of those is active — no banner collision possible.
• dismissValidationErrors() still clears the banner on next drop: processDrop calls it first, so dropping a valid file after invalid ones automatically clears the yellow warning — consistent with the PR's stated intent.
• sortedFiles fix is minimal and correct: the one-line change from a single equality check to a two-condition OR is exactly scoped to the bug, with no unintended side effects on activeCount (which independently excludes both rejected and validationError).
• makeObservable entry added for hasValidationErrors: properly declared as computed on line 94 — MobX reactivity is wired up correctly.
• Comprehensive CHANGELOG [Unreleased] section: both the sorting fix and the validation-error banner behaviour are covered by the existing entries, so no additional changelog work is needed.