fix(frontend, v1.3): remove the clear button from the dataset version picker - #8619
Merged
mengw15 merged 1 commit intoSep 21, 2026
Conversation
apache#8343) ### What changes were proposed in this PR? The version dropdown on a dataset's detail page carried nzAllowClear, so clicking the × emitted null into onVersionSelected(version: DatasetVersion), which read this.selectedVersion.dvid and threw an uncaught TypeError. The page was left half-cleared: the main pane said "No version is selected" while the header still showed the cleared version's file path and the file tree still listed its files. Clearing the selection is not a meaningful action on a page whose entire content is one version, so the button goes away. The model detail page already works this way. dataset-detail.component.html — drop nzAllowClear from the version nz-select. dataset-detail.component.ts — onVersionSelected takes DatasetVersion | undefined and skips the fetch when there is no dvid, so an empty selection cannot throw even if the control pushes one (an empty version list, for instance). Mirrors model-detail.component.ts. Picking a version behaves exactly as before: same request, same arguments. Before — the × in the dropdown, and the page after clicking it (console output overlaid so it fits in one screenshot): <img width="1440" height="900" alt="image" src="https://github.com/user-attachments/assets/8780a9e5-e135-4281-9120-9cbe898639c4" /> <img width="1440" height="900" alt="image" src="https://github.com/user-attachments/assets/3edcf630-fc06-4c5f-9bab-e916f10e03c7" /> After — same dropdown hovered, no clear button: <img width="1440" height="900" alt="image" src="https://github.com/user-attachments/assets/a837ab1e-06b8-4d8c-a43e-540c4142b51f" /> ### Any related issues, documentation, discussions? Closes apache#8342 ### How was this PR tested? Two cases added to dataset-detail.component.spec.ts: survives the version select being emptied — onVersionSelected(undefined) neither throws nor fetches. Without the signature change it does not compile. offers no way to empty the selection — the rendered picker has no clear control. ``` cd frontend npx ng test --include src/app/dashboard/component/user/user-dataset/user-dataset-explorer/dataset-detail.component.spec.ts # Tests 144 passed (144) ``` Also checked by hand against a local stack: hovering the version dropdown on a dataset with two versions no longer offers a ×, switching versions still reloads the file tree and preview, and the console stays clean. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 5) (backported from commit 83e71c2)
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 #8619 +/- ##
===============================================
Coverage 94.06% 94.07%
Complexity 4808 4808
===============================================
Files 1194 1194
Lines 48601 48601
Branches 5860 5860
===============================================
+ Hits 45718 45719 +1
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:
|
This was referenced Sep 21, 2026
xuang7
approved these changes
Sep 21, 2026
mengw15
deleted the
backport/8343-remove-the-clear-button-from-the-dataset-v1.3
branch
September 21, 2026 20:26
renovate-bot
pushed a commit
to renovate-bot/apache-_-texera
that referenced
this pull request
Sep 21, 2026
…pache#8626) ### What changes were proposed in this PR? `Direct Backport Push` cherry-picks a cleanly-applying fix onto the release branch and pushes it. Every one of those pushes has been rejected since 2026-07-24: `release/*` is covered by the Merge Queue ruleset, which requires a pull request of everyone. apache#8379 tried to exempt the Actions app from it; GitHub refuses to create that bypass, and apache#8624 reverts it. ASF policy points the same way — an automated service must not push to a branch subject to official release without prior authorization from Infrastructure. Both outcomes now open a pull request. The conflicted one is unchanged: a draft, assigned to its author. A clean one opens **ready for review and assigned to nobody**, because there is no code for anyone to write on it. What a clean backport still needs is its checks started, and that is the part worth stating plainly. GitHub creates no workflow run for anything `GITHUB_TOKEN` does, so a bot-opened pull request has none — and nothing will arrive on its own: | action on a pull request with no checks | starts the three required contexts | | --- | --- | | push any commit to the branch | yes (`synchronize`) | | close and reopen it | yes (`reopened`) | | mark it ready for review | **no** — none of the three workflows listens for `ready_for_review` | | add or remove a label | only `Required Checks` | | "Re-run all jobs" | no — with no run there is nothing to re-run | A conflicted backport never had this problem: its author pushes a resolution, and that push brings CI with it. A clean one has nobody to push anything. So the comment the conflict path already posts for its instructions now says, for a clean backport, the one action that works — and says that marking it ready for review is not it. That leaves the release manager three ordinary buttons: reopen, approve, and auto-merge if they would rather not come back when the checks finish. The approval is not automated and should not be: the `release/*` label on the original PR records the decision, and this is the look at the tree that actually lands. Nothing here depends on a token's pull-request scope, on an Actions bypass, or on a close/reopen the workflow performs itself. Those are the paths that can only be proven in production, and that fail quietly when they are wrong — which is how apache#8432, apache#8494 and apache#8562 were lost. `push_entries` is now always empty, leaving `push-backports` unreachable. Removing it is left to a separate change, so that this one is a behaviour change and that one is a pure deletion. ### Any related issues, documentation, discussions? Closes apache#8377. apache#8378 proposed the same routing with the workflow performing the close/reopen itself and arming auto-merge; this drops both in favour of the release manager's own click, and is closed in favour of this. ### How was this PR tested? The routing was driven locally against a stubbed `github-script` environment. With the pre-merge preflight green, both targets come out as pull-request entries carrying `clean: "true"` and `push_entries` empty; with it neutral, `clean: "false"`; with no completed signal, neither target is acted on, as before. Restoring the old `pushEntries.push` turns that check red, so it is not vacuous. The workflow parses, and all four inline `github-script` bodies pass `node --check`. That a bot-opened pull request starts with no checks is what this repository already shows: apache#8584 — bot-opened, one commit, nobody pushed to it — carries no check runs at all, while apache#8553, opened the same way, has the full set after a commit was pushed. That `ready_for_review` does not start them is in the triggers: `required-checks.yml` lists `opened`/`reopened`/`synchronize`/`labeled`/`unlabeled`, `check-header.yml` takes the bare `pull_request:` defaults, and `lint-pr.yml` lists `opened`/`edited`/`reopened`/`synchronize`. Not provable before merge: that a human reopen produces the three contexts on a backport PR. apache#8619 to apache#8623 — five backports into `release/v1.3` opened by hand this week — show that the contexts do appear and pass on a pull request into a release branch; the reopen path shares everything with them but the event that starts the run. ### Was this PR authored or co-authored using generative AI tooling? Yes. Generated-by: Claude Code (claude-opus-5)
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 #8343 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 #8343 for the change itself (the version dropdown'snzAllowClearemittednullinto a handler typedDatasetVersion, throwing an uncaughtTypeErrorand leaving the page half-cleared).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 33705892851). 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 #8343. See #8377.Source: 83e71c2
Any related issues, documentation, discussions?
Backport of #8343. Originally linked #8342.
How was this PR tested?
The change is identical to #8343, 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.Was this PR authored or co-authored using generative AI tooling?
Yes. Generated-by: Claude Code (claude-opus-5)