fix(frontend, v1.3): refresh a dataset's paths after a rename, and block renaming mid-upload - #8620
Merged
mengw15 merged 1 commit intoSep 21, 2026
Conversation
…naming mid-upload (apache#8347) ### What changes were proposed in this PR? Every file path on a dataset's detail page embeds the dataset name, and preview and single-file download resolve a dataset by (owner, name). `onSaveDatasetName()` updated the displayed name and nothing else, so after a rename the page kept serving the old paths: the file tree and the path above the preview still said the old name, clicking a file hung on "File content is loading" (404, then 500), and the Data Card's "Latest version file" was stale too. Only a reload recovered. The same rename was also allowed while an upload was running. The upload is addressed by the name it started with, so the data uploaded fine and then the completing call failed with `400 {"code":400,"message":"Dataset not found"}`, leaving the panel on "Uploading: 1 file(s)" forever and a row behind in `dataset_upload_session`. - `dataset-detail.component.ts` — after a successful rename, refetch the browsed version's file tree and the Data Card's latest-version facts. The selected version is kept deliberately; `retrieveDatasetVersionList()` would also refresh both but resets the picker to the newest version, which a rename is no reason to do. - `dataset-detail.component.ts` / `.html` — bind the uploader's existing `uploadsInFlightChange`, disable the name field and Save while an upload is running, show a hint saying why, and guard `onSaveDatasetName()` on the same invariant. Note the browsed file resets to the version's first file after a rename, because the dataset page does not track the open file's relative path the way the model page does. That is a small change in behaviour from a page that was previously broken; tracking the open path can follow separately if it is worth it. **Before** — renamed, but the path still says `sensor-readings` and the preview hangs (console output overlaid so it fits in one screenshot); the Data Card keeps the old path too: <img width="1440" height="900" alt="image" src="https://github.com/user-attachments/assets/330c06d6-a65a-409c-bf80-53b46c4d334c" /> <img width="1440" height="900" alt="image" src="https://github.com/user-attachments/assets/53da25ab-2220-45f3-96c0-6f7012202bc0" /> **After** — the path and the Data Card both follow the new name, and the file opens: <!-- attach issue2-2-stale-tree-after.png --> <!-- attach issue2-4-data-card-after.png --> **After** — renaming is blocked while an upload is in flight: <img width="1440" height="900" alt="image" src="https://github.com/user-attachments/assets/7b0a7540-82fe-4403-8de3-eb9e2dae119b" /> ### Any related issues, documentation, discussions? Closes apache#8345. ### How was this PR tested? Three cases added to `dataset-detail.component.spec.ts`: - `refetches the file tree and the latest-version facts, which both embed the old name` — asserts both fetches happen with the browsed `dvid`, and that the selected version is unchanged. Removing the two refresh calls fails this test. - `refuses to rename while an upload is in flight, which would strand it`. - `locks the name field while an upload is in flight` — drives the real uploader output through the rendered template and checks the input and Save button are disabled. ``` cd frontend npx ng test --include src/app/dashboard/component/user/user-dataset/user-dataset-explorer/dataset-detail.component.spec.ts # Tests 145 passed (145) ``` Also checked by hand against a local stack, with the file uploads throttled so the upload stays in flight: renaming now leaves the tree, the path header and the Data Card all on the new name and files still open, and the name field is greyed out with the hint while an upload runs. ### Was this PR authored or co-authored using generative AI tooling? (backported from commit 4ff0b8b) Generated-by: Claude Code (Opus 5)
Contributor
Automated Reviewer SuggestionsBased on the
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## release/v1.3 #8620 +/- ##
===============================================
Coverage 94.06% 94.07%
Complexity 4808 4808
===============================================
Files 1194 1194
Lines 48601 48615 +14
Branches 5860 5862 +2
===============================================
+ Hits 45718 45733 +15
Misses 1429 1429
+ Partials 1454 1453 -1
*This pull request uses carry forward flags. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
mengw15
deleted the
backport/8347-refresh-a-dataset-s-paths-after-a-rename-v1.3
branch
September 21, 2026 20:32
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this PR?
Backport of #8347 to
release/v1.3: a clean cherry-pick of its squash commit, no adaptations — the backport commit reuses the squash message and author, as the automated fast path would. See #8347 for the change itself (after a rename the detail page kept serving the old paths, so file preview and single-file download 404'd until a reload; renaming during an upload was also allowed).Opened manually by the v1.3 release manager: the automated fast path cherry-picked this cleanly and then pushed it straight to
release/v1.3, where the Merge Queue ruleset rejected the push (GH013, run 33706287941). The Actions-app bypass meant to unblock that path (#8379) was never created — asfyaml rejects anIntegrationbypass actor — and the failing job's notification 403s for want ofpull-requests: write, so the loss left neither a backport PR nor a comment on #8347. See #8377.Source: 4ff0b8b
Any related issues, documentation, discussions?
Backport of #8347. Originally linked #8345.
How was this PR tested?
The change is identical to #8347, which carries the specs (
dataset-detail.component.spec.ts); the backport tree is verified byte-identical to cherry-picking the squash commit ontorelease/v1.3, and release-branch CI runs the full matrix on this PR. It touches the same three files as #8343's backport; the two apply cleanly onto this branch in either order.Was this PR authored or co-authored using generative AI tooling?
Yes. Generated-by: Claude Code (claude-opus-5)