fix: preserve active time period when applying dimension filters

[impoiler]

Summary

Fixes a bug where applying dimension filters (providers, models, keys, etc.) from the sidebar or header would inadvertently clear the active time period. In period mode, newFilters carries no start_time/end_time, so the previous logic was unconditionally writing undefined for those values and wiping the selected period. Time state is now only updated when an explicit start and end time are both present.

Also fixes navigation links in the log detail view that were replacing the entire search state instead of merging into it, which caused the active time range and other filters to be lost when clicking through to filtered log views.

Changes

• setFilters on both the dashboard and logs pages now checks for hasExplicitTime before touching time-related URL state. If no explicit range is provided, the existing period, start_time, and end_time values are left untouched.
• start_time/end_time are now written inside the conditional timeChanged block rather than unconditionally, removing the path that could set them to undefined.
• All search={{ ... }} props on filter links in logDetailView.tsx have been changed to search={(prev) => ({ ...prev, ... })} so that existing URL state (including the active time range) is preserved when navigating.

Type of change

• Bug fix
• Feature
• Refactor
• Documentation
• Chore/CI

Affected areas

• Core (Go)
• Transports (HTTP)
• Providers/Integrations
• Plugins
• UI (React)
• Docs

How to test

1. Set a relative time period (e.g. "Last 24 hours") on the Logs or Dashboard page.
2. Apply a dimension filter (e.g. select a provider or model) from the sidebar or header.
3. Verify the active time period is still selected and the data is filtered correctly — it should not revert to an empty/default time range.
4. Open a log detail view, click a filter link (e.g. a routing rule, key, team, or customer).
5. Verify the logs page opens with both the clicked filter and the previously active time range applied.

cd ui
pnpm i || npm i
pnpm build || npm run build

Breaking changes

• Yes
• No

Related issues

Security considerations

None.

Checklist

• I read docs/contributing/README.md and followed the guidelines
• I added/updated tests where appropriate
• I updated documentation where needed
• I verified builds succeed (Go and UI)
• I verified the CI pipeline passes locally if applicable

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 40 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 83bfa0f8-b85a-470c-8a5f-ce0dc0e85887

📥 Commits

Reviewing files that changed from the base of the PR and between 4e48235 and 9dd49c4.

📒 Files selected for processing (3)

• ui/app/workspace/dashboard/page.tsx
• ui/app/workspace/logs/page.tsx
• ui/app/workspace/logs/sheets/logDetailView.tsx

📝 Walkthrough

Walkthrough

This PR changes dashboard and logs filter handling so absolute time fields are only written when both start_time and end_time are present. It also updates log detail navigation links to merge new filter params with existing query state.

Changes

Filter and query param preservation

Layer / File(s)	Summary
Dashboard setFilters explicit time-range handling ui/app/workspace/dashboard/page.tsx	setFilters checks for both start_time and end_time before converting to unix timestamps and updating time-related URL state.
Logs setFilters explicit time-range handling ui/app/workspace/logs/page.tsx	setFilters uses an explicit start/end check for userModifiedTimeRange and period clearing, and removes conditional population of start_time/end_time from the shared URL update path.
LogDetailView links use functional search updaters ui/app/workspace/logs/sheets/logDetailView.tsx	Links for routing rules, keys, teams, customers, business units, and users now merge with existing query params instead of replacing them.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Possibly related PRs

• maximhq/bifrost#4801: Both PRs modify ui/app/workspace/dashboard/page.tsx’s setFilters URL-state adapter around period/start_time/end_time handling.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly summarizes the main bug fix of preserving the active time period when applying dimension filters.
Description check	✅ Passed	The description is largely complete and matches the template, including summary, changes, testing, and impact sections.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 07-08-fix_unwated_filters_resets_on_dashboard_and_logs_pages

---

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

[impoiler]

• feat: add object storage archival docs for audit logs #4992
• feat: add S3/GCS object storage config schema for audit log archival #4991
• feat: add schema_url/BIFROST_SCHEMA_URL support for mirrored schema locations in isolated deployments #4614
• fix: preserve active time period when applying dimension filters #5030 👈 (View in Graphite)
• fix: match model filter on canonical_model_name and restore routing info for cost recalc #5029
• feat: replace SSE streaming with background job polling for cost recalculation #5006
• feat: migrate cost recalculation to durable background sidekiq job with resume and dedup #5005
• feat: add GetInFlightSidekiqJobByKind to config store interface #5004
• feat: add durable background-job sidekiq table, store methods, and runner with recovery and reaper #4989 : 1 other dependent PR (#5000 )
• dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Confidence Score: 5/5

Safe to merge — all three files make narrowly scoped, correct changes to URL state management with no regressions to existing functionality.

The time-guard logic is sound: both hasExplicitTime checks correctly require both timestamps to be present before touching time-related URL state. The timeChanged comparisons are type-compatible with the existing URL state representations. The functional search merge in logDetailView.tsx is the standard TanStack Router pattern for partial state updates, and adding offset: 0 and selected_log addresses the two edge cases flagged in prior review threads. No data-testid attributes are removed and no browser crypto APIs are introduced.

No files require special attention.

Important Files Changed

Filename	Overview
ui/app/workspace/dashboard/page.tsx	setFilters now guards time-range writes behind hasExplicitTime, preventing dimension-filter actions from clearing the active period or absolute range
ui/app/workspace/logs/page.tsx	Same hasExplicitTime guard applied; start_time/end_time writes moved inside the conditional timeChanged block, removing the path that set them to undefined on dimension-filter changes
ui/app/workspace/logs/sheets/logDetailView.tsx	All filter-navigation links converted from static search objects to functional merges (prev => {...prev, offset:0, selected_log:'', ...filter}), preserving time range and resetting offset/sheet state on navigation

_{Reviews (16): Last reviewed commit: "fix: unwated filters resets on dashboard..." | Re-trigger Greptile}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@ui/app/workspace/logs/sheets/logDetailView.tsx`:
- Around line 743-749: The detail-sheet filter links are preserving the current
pagination state because the Link search updater spreads prev without resetting
offset. Update each search callback in logDetailView.tsx (the badge/link
handlers such as the routing_rule link) to explicitly set offset to 0 alongside
the new filter ids so navigation always lands on the first page of the filtered
results.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 84019987-d78e-4e5b-b784-00173895bed7

📥 Commits

Reviewing files that changed from the base of the PR and between a2be949 and efee0f3.

📒 Files selected for processing (3)

• ui/app/workspace/dashboard/page.tsx
• ui/app/workspace/logs/page.tsx
• ui/app/workspace/logs/sheets/logDetailView.tsx

[Pratham-Mishra04]

Merge activity

• Jul 9, 12:16 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Jul 9, 12:34 PM UTC: Graphite rebased this pull request as part of a merge.
• Jul 9, 12:35 PM UTC: @Pratham-Mishra04 merged this pull request with Graphite.

The base branch was changed.