You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
bug: Bug: Sidebar active highlight disappears on detail pages #5094
The sidebar navigation item loses its active highlight when navigating from a section's main page to its detail page. This happens in sections like Tasks and Runs, making it difficult for users to identify their current location in the dashboard.
Reproduction repo
Not applicable. The issue is reproducible directly in the Trigger.dev Cloud Dashboard.
To reproduce
Open a project environment in the Trigger.dev dashboard.
Click on Tasks in the sidebar.
Verify that Tasks is highlighted.
Open any task from the list.
Observe that the Tasks highlight disappears.
Repeat the same steps with Runs by opening an individual run.
Suggested fix
Investigate the sidebar pathname matching logic and support prefix-based matching for nested detail routes. Ensure that the correct parent menu item remains active without affecting other navigation items.
Additional information
The issue occurs when navigating to detail pages, but not when applying filters on list pages. It appears to be related to exact pathname matching in the sidebar navigation logic.
I investigated this issue and traced the root cause in the sidebar navigation matching logic:
Root Cause
In SideMenuItem.tsx, route active status is computed as pathName === to || (matchPrefix && pathName.startsWith(${to}/)).
In SideMenu.tsx, main menu items (Runs, Sessions, Webhooks) do not pass matchPrefix, so navigating to any child detail page (e.g. /runs/:id) causes exact pathname matching to fail and drops the active highlight.
For Tasks, to points to the environment root (v3EnvironmentPath). Setting a naive matchPrefix on to would greedily match all sibling routes (/runs, /batches, /settings), whereas task detail pages live specifically under ${v3EnvironmentPath}/tasks/ (e.g. /tasks/standard/:id, /tasks/scheduled/:id, /tasks/stream, /tasks/dashboard).
Proposed Solution
Extend SideMenuItem: Support explicit prefix matching (e.g. allowing matchPrefix to accept a custom prefix string like ${v3EnvironmentPath}/tasks or adding an activePrefix?: string prop).
Update SideMenu.tsx: Enable prefix matching on Runs, Sessions, Webhooks, and supply the /tasks sub-path prefix for Tasks.
Update sideMenuSections.tsx: Ensure detail-bearing section items (batches, deployments, errors, bulk-actions, waitpoint-tokens) also enable matchPrefix: true, matching the pattern already used for alerts.
Tests: Add regression unit tests in apps/webapp/test/ verifying active highlight retention across nested detail paths.
I'd like to take this up and submit a PR with test coverage. Could you please assign this issue to me?
Activity
dhruvil-codes commentedon Nov 4, 2026
Hi team,
I investigated this issue and traced the root cause in the sidebar navigation matching logic:
Root Cause
SideMenuItem.tsx, route active status is computed aspathName === to || (matchPrefix && pathName.startsWith(${to}/)).SideMenu.tsx, main menu items (Runs,Sessions,Webhooks) do not passmatchPrefix, so navigating to any child detail page (e.g./runs/:id) causes exact pathname matching to fail and drops the active highlight.Tasks,topoints to the environment root (v3EnvironmentPath). Setting a naivematchPrefixontowould greedily match all sibling routes (/runs,/batches,/settings), whereas task detail pages live specifically under${v3EnvironmentPath}/tasks/(e.g./tasks/standard/:id,/tasks/scheduled/:id,/tasks/stream,/tasks/dashboard).Proposed Solution
SideMenuItem: Support explicit prefix matching (e.g. allowingmatchPrefixto accept a custom prefix string like${v3EnvironmentPath}/tasksor adding anactivePrefix?: stringprop).SideMenu.tsx: Enable prefix matching onRuns,Sessions,Webhooks, and supply the/taskssub-path prefix forTasks.sideMenuSections.tsx: Ensure detail-bearing section items (batches,deployments,errors,bulk-actions,waitpoint-tokens) also enablematchPrefix: true, matching the pattern already used foralerts.apps/webapp/test/verifying active highlight retention across nested detail paths.I'd like to take this up and submit a PR with test coverage. Could you please assign this issue to me?
Thanks!