fix: monitor filter state syncing [ENG-2401]

[speaker-ender]

Ticket ENG-2401

Description Of Changes

Fixing an out-of-sync state handling where the MonitorFieldFilters component was not reflecting the current state of the applied filters.

Code Changes

• Removing unnecessary reset of the local state that reverted to an older version of the filters due to a race condition
• Minor refactors to existing code

Steps to Confirm

1. Visit a monitor screen
2. Change the filters
3. Confirm that re-opening the filters popover contains the correct values after applying or not applying your selections

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
  • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
  • Updates unreleased work already in Changelog, no new entry necessary
• UX feedback:
  • All UX related changes have been reviewed by a designer
  • No UX review needed
• Followup issues:
  • Followup issues created
  • No followup issues
• Database migrations:
  • Ensure that your downrev is up to date with the latest revision on main
  • Ensure that your downgrade() migration is correct and works
    • If a downgrade migration is not possible for this change, please call this out in the PR description!
  • No migrations
• Documentation:
  • Documentation complete, PR opened in fidesdocs
  • Documentation issue created in fidesdocs
  • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
  • No documentation updates required

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Review	Updated (UTC)
fides-plus-nightly	Ignored	Preview	Jan 16, 2026 6:57pm
fides-privacy-center	Ignored		Jan 16, 2026 6:57pm

[greptile-apps]

Greptile Summary

This PR fixes an out-of-sync state handling issue in the MonitorFieldFilters component by removing unnecessary reset logic that caused a race condition when the popover closed.

Changes made:

• Removed state reset on popover close (handleOpenChange) that was reverting to older filter values
• Simplified checkedKeys and activeFiltersCount by removing unnecessary useMemo wrappers
• Added as const assertion to CONFIDENCE_BUCKETS array

Critical issue found:
The PR removes the problematic reset logic but doesn't add the proper solution: useEffect hooks to sync local state with applied state changes. Without these effects, the local state (what shows in the popover) won't update when the applied state changes externally through URL changes, reset buttons, or other components. This will cause the popover to display stale values after external state changes.

Confidence Score: 2/5

• This PR has a critical missing piece that will cause incorrect UI state after external filter changes
• While the PR correctly identifies and removes the race condition caused by resetting state on popover close, it doesn't implement the proper solution. Without useEffect hooks to sync local state with applied state, the popover will show stale values whenever filters are changed externally (via URL, reset buttons, or other components). The component initializes local state once but never updates it.
• Pay close attention to MonitorFieldFilters.tsx - it needs useEffect hooks added to sync local state with applied state

Important Files Changed

Filename	Overview
clients/admin-ui/src/features/data-discovery-and-detection/action-center/fields/MonitorFieldFilters.tsx	Removed unnecessary state reset on popover close, simplified useMemo usage, but missing useEffect to sync local state with applied state changes

[greptile-apps]

Additional Comments (1)

1. clients/admin-ui/src/features/data-discovery-and-detection/action-center/fields/MonitorFieldFilters.tsx, line 162-171 (link)

   logic: Missing useEffect to sync local state with applied state changes. The local state is initialized once with useState(resourceStatus), but if resourceStatus, dataCategory, or confidenceBucket change externally (e.g., from URL changes, reset actions, or other components), the local state won't update. This means the popover will show stale values.

   Add after line 171:

_{2 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[speaker-ender]

Additional Comments (1)

1. clients/admin-ui/src/features/data-discovery-and-detection/action-center/fields/MonitorFieldFilters.tsx, line 162-171 (link)
   logic: Missing useEffect to sync local state with applied state changes. The local state is initialized once with useState(resourceStatus), but if resourceStatus, dataCategory, or confidenceBucket change externally (e.g., from URL changes, reset actions, or other components), the local state won't update. This means the popover will show stale values.
   Add after line 171:

2 files reviewed, 2 comments

Edit Code Review Agent Settings | Greptile

The state doesn't need to be synced in this way.
The component re-loads with the correct state when opened.
There shouldn't be background interactions effecting this.