Load a deep-linked job's details first, and only its push - #9823
Open
camd wants to merge 1 commit into
Open
Conversation
✅ Deploy Preview for treeherder ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #9823 +/- ##
==========================================
- Coverage 83.88% 83.86% -0.03%
==========================================
Files 643 643
Lines 39264 39341 +77
Branches 3492 3457 -35
==========================================
+ Hits 32937 32992 +55
- Misses 5938 6204 +266
+ Partials 389 145 -244 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
When the jobs view is opened with a selectedTaskRun or selectedJob URL param and no push-range params, resolve the job via the jobs API before fetching any pushes, so the details panel starts loading immediately. The URL is then rewritten to revision=<the job's push> and only that push is fetched, instead of the latest 10; "Get next N" works from there for users who want more context. Explicit range params still win (the job is still resolved eagerly for details-first loading). Scrolling to the selected job is now driven by a pending-scroll flag that is consumed by whichever happens first: the job button mounting, or the post-load selection sync finding the rendered button. The post-load sync also no longer clears an eagerly-resolved selection, and updateRange keeps the selection when narrowing to the push that contains it.
camd
force-pushed
the
camd/selected-job-first-load
branch
from
September 6, 2026 20:37
d4c27ac to
2c9cebe
Compare
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
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.
Problem
Opening Treeherder with a job or task id in the URL (
selectedTaskRunorselectedJob) loaded the latest 10 pushes and all of their job lists before the selection was even resolved — the details panel was the last thing to appear, and the view often failed to scroll to the job. If you deep-link to a job, you want that job's details first.Changes
Job first, then only its push. On a deep link with no push-range params:
resolveSelectedJobFromUrl()(selectedJobStore) resolves the task viaGET /api/jobs/?task_id=…(or?id=…) before any push traffic and sets the selection immediately, so the details panel starts loading right away.revision=<the job's push>(keepingselectedTaskRun, normalizingselectedJob→selectedTaskRun), and only that push is fetched (fetchInitialPushes()in pushesStore) instead of the latest 10. "Get next N" works from there for users who want surrounding context.revision,fromchange, dates,author) still win: no rewrite, but the job is still resolved eagerly for details-first loading. An unresolvable task shows the existing notification and falls back to the default view.Reliable scroll. The old mount-time one-shot scroll in
useJobButtonRegistryfired while other pushes were still inserting DOM (layout shifted after the scroll) and never fired for collapsed groups. It's replaced by a pending-scroll flag consumed by whichever happens first: the job button mounting, or the post-load selection sync finding the rendered button.Fixed along the way
updateRangekeeps the selection when narrowing to the push that contains it (previously it cleared the selection unconditionally; React Router v7 applies popstate in a transition, so PushList could see a phantom range diff after the URL rewrite and clobber the selection).searchDatabaseForTaskRunno longer sends the literalretry_id=undefinedwhen the URL has no run id.Filtering_testnow resetswindow.locationbetween tests — job-click tests leakedselectedTaskRuninto the shared URL, which a fresh App mount now correctly treats as a deep link.Tests
tests/ui/job-view/SelectedJobFirstLoad_test.jsx— end-to-end (BrowserRouter): asserts the resolve request precedes any push request, exactly one push fetch limited to the job's revision, the URL rewrite, the selected button, and the scroll.tests/ui/job-view/stores/selectedJobEagerResolve_test.jsx— resolution (run-id/none/job-id, highest-retry pick, not-found), keep-vs-clear selection semantics, pending-scroll consumption.tests/ui/shared/stores/fetchInitialPushes_test.jsx— orchestration: single-push fetch + rewrite, explicit-range passthrough, no-selection default, not-found fallback.tests/ui/hooks/useJobButtonRegistry.test.js.Full suite: 102 suites / 1109 tests pass; lint clean.
Note for sheriffs
Deep links to a job now show one push instead of the latest 10 — "Get next 10" restores the surrounding range, and any explicit range param preserves the old behavior.