fix(dashboard): continuously apply log filter during live run

[ericallam]

No description provided.

[changeset-bot]

⚠️ No Changeset found

Latest commit: ea544f1

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai]

Walkthrough

The concreteStateFromInput function in apps/webapp/app/components/primitives/TreeView/utils.ts has been refactored to return the result of applyFilterToState() instead of directly constructing and returning a state object. Previously, visibleNodeIds was computed directly via visibleNodes(tree, nodes).map(...); now the function delegates this visibility and filter handling logic to applyFilterToState() with visibleNodeIds initialized to an empty array, routing initial state through filter-aware state transformation.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify that delegating to applyFilterToState() with an empty visibleNodeIds array produces identical behavior to the previous direct computation path
• Confirm that applyFilterToState() properly handles the no-filter case and correctly recomputes visibility fields when needed
• Check that the change maintains backward compatibility with existing callers of concreteStateFromInput()

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	No pull request description was provided; the required template sections (Testing, Changelog, issue reference) are entirely missing.	Add a complete description following the repository template: reference the issue, describe testing steps, provide a changelog summary, and complete the checklist.
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the fix scope (dashboard) and specific behavior being improved (log filter persistence during live run), directly matching the code change.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/run-dashboard-filter-persistence

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1a7ee24 and ea544f1.

📒 Files selected for processing (1)

• apps/webapp/app/components/primitives/TreeView/utils.ts (1 hunks)

🧰 Additional context used

🧠 Learnings (1)

📓 Common learnings

Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 2390
File: apps/webapp/app/runEngine/services/batchTrigger.server.ts:787-795
Timestamp: 2025-08-14T20:37:30.914Z
Learning: The webapp uses ts-reset which provides better TypeScript type narrowing for common patterns like filter(Boolean), making explicit type guards unnecessary in many cases.

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (23)

• GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 8)
• GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
• GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
• GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
• GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
• GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
• GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
• GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
• GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
• GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
• GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
• GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
• GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
• GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
• GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
• GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
• GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
• GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
• GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
• GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
• GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
• GitHub Check: typecheck / typecheck
• GitHub Check: Analyze (javascript-typescript)

🔇 Additional comments (1)

apps/webapp/app/components/primitives/TreeView/utils.ts (1)

42-49: LGTM! Filter now properly applied during initial state creation.

This change correctly delegates to applyFilterToState, ensuring that filters are applied from the initial state rather than only on subsequent updates. This aligns perfectly with the PR objective to "continuously apply log filter during live run."

The approach is clean: applyFilterToState will compute the proper visibleNodeIds and handle filter logic whether a filter is present or not (lines 99-107 for no filter, lines 119-206 for active filter).

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}