fix(frontend): don't count dropped folders as failures

[Raja-Hamid]

Dropping a folder onto the dataset file uploader reported "1 file failed to be selected." even though nothing failed and nothing was meant to be uploaded.

fileDropped settles one promise per dropped entry, and there are three outcomes: a valid file resolves to an item, a directory deliberately resolves to null, and an oversized or unreadable file rejects. The failure count was derived from the difference between the total settled results and the non-null successes, so a directory -- fulfilled, but filtered out as null -- was indistinguishable from a genuine rejection.

Count the rejected results directly instead. Directories are ignored silently, while files that really did fail are still reported, with the existing singular/plural wording.

Closes #7457

What changes were proposed in this PR?

Dropping a folder onto the dataset file uploader showed a red banner reading "1 file failed to be selected." — even though nothing failed and nothing was meant to be uploaded. Valid files dropped alongside it were still selected correctly; only the banner was wrong.

fileDropped settles one promise per dropped entry (files-uploader.component.ts:283-312), with three possible outcomes:

Outcome	How it settles	In successfulUploads?	In results?
valid file	resolve({...})	yes	yes
directory	resolve(null) (:310)	no — filtered out as null	yes
oversized / unreadable	reject(...) (:295, :306)	no	yes

successfulUploads keeps only fulfilled non-null values (:319-322), but the failure count was derived from the raw length:

const failedCount = results.length - successfulUploads.length;

That difference equals rejections + directories. A directory is fulfilled-with-null, never a rejection, so it was indistinguishable from a genuine failure and inflated the count.

The fix counts rejections directly, as the issue proposes:

const failedCount = results.filter(result => result.status === "rejected").length;

resolve(null) occurs only in the non-file branch, so fulfilled-null corresponds exactly to a directory, and both reject sites are real failures. Directories are now ignored silently; files that genuinely failed are still reported, with the singular/plural wording untouched.

The behaviour change is limited to that banner — selection, conflict resolution, and emission are unaffected.

Any related issues, documentation, discussions?

Closes #7457

How was this PR tested?

Added five tests under describe("dropped folders are not failures") in files-uploader.component.spec.ts, plus a droppedDirectory() helper building an entry with isFile: false (the existing droppedFile() helper always sets isFile: true):

• a folder on its own produces no banner at all — asserts fileUploadingFinished === false and an empty message
• a folder alongside a valid file yields the success banner only, and emits just that file
• an oversized file on its own still reports 1 file failed to be selected. — green before and after, guarding the real-failure path
• a folder plus an oversized file counts exactly 1, not 2
• a folder plus two oversized files keeps the plural 2 files failed to be selected.

Command:

corepack yarn ng test --watch=false \
  --include="**/files-uploader.component.spec.ts"

• Against unmodified source: 4 failed, 31 passed (35). The plural case reported 3 files failed to be selected. where 2 files failed to be selected. was expected — the dropped folder inflating the count.
• After the fix: 35/35 passing.

Regression sweep including dataset-detail.component.spec.ts, the only component embedding the uploader:

corepack yarn ng test --watch=false \
  --include="**/files-uploader.component.spec.ts" \
  --include="**/dataset-detail.component.spec.ts"

Result: 2 files, 230/230 passing. yarn prettier-eslint reports both touched files unchanged.

Before / after: dropping a folder previously raised a red "1 file failed to be selected." banner; it now completes silently.

Was this PR authored or co-authored using generative AI tooling?

Generated-by: Yes, Alongside Claude Code

[github-actions]

Backport auto-label report

This fix: PR was checked against each actively-supported release branch. release/* labels drive the post-merge backport, so add or remove one to change where this fix lands.

Release branch	Analysis
✅ release/v1.2	Change detected on this branch — label added; this fix is queued to backport here. Requested review from @xuang7.

Auto-label run.

[github-actions]

Automated Reviewer Suggestions

Based on the git blame history of the changed files, we recommend the following reviewers:

• Contributors with relevant context: @mengw15, @Yicong-Huang
  You can notify them by mentioning @mengw15, @Yicong-Huang in a comment.

[Raja-Hamid]

@aglinxinyuan , Kindly review this.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.59%. Comparing base (1f5d2e6) to head (2f2c389).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #7841      +/-   ##
============================================
+ Coverage     91.58%   91.59%   +0.01%     
  Complexity     4501     4501              
============================================
  Files          1173     1173              
  Lines         47352    47350       -2     
  Branches       5307     5306       -1     
============================================
+ Hits          43366    43369       +3     
+ Misses         2342     2336       -6     
- Partials       1644     1645       +1     

Flag	Coverage Δ		*Carryforward flag
access-control-service	81.00% <ø> (ø)		Carriedforward from 1f5d2e6
agent-service	98.62% <ø> (ø)		Carriedforward from 1f5d2e6
amber	88.12% <ø> (ø)		Carriedforward from 1f5d2e6
computing-unit-managing-service	73.67% <ø> (ø)		Carriedforward from 1f5d2e6
config-service	86.73% <ø> (ø)		Carriedforward from 1f5d2e6
file-service	75.74% <ø> (ø)		Carriedforward from 1f5d2e6
frontend	93.37% <100.00%> (+0.02%)	⬆️
notebook-migration-service	79.13% <ø> (ø)		Carriedforward from 1f5d2e6
pyamber	97.57% <ø> (ø)		Carriedforward from 1f5d2e6
workflow-compiling-service	77.19% <ø> (ø)		Carriedforward from 1f5d2e6

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.