Skip to content

Stop the audit capability probe from scanning the whole store - #3109

Open
ramonsmits wants to merge 2 commits into
ramon/audit-super-date-pickerfrom
ramon/audit-capability-probe
Open

Stop the audit capability probe from scanning the whole store#3109
ramonsmits wants to merge 2 commits into
ramon/audit-super-date-pickerfrom
ramon/audit-capability-probe

Conversation

@ramonsmits

Copy link
Copy Markdown
Member

Stacked on:

Two bug fixes for the hasSuccessfulMessages capability probe, found while profiling the slow first load of All Messages on a large store.

  • The probe was the slow query, not the list. The probe ran an unbounded sorted query over the whole audit index, re-fired every 5 seconds by the platform-capabilities poll, on every view. It now probes the last 7 days first, falls back to unbounded only when that window is empty, and never re-probes after a positive answer.
  • Onboarding prompts rendered on an assumption. The "no successful audit messages" flag started as false, so the Messages indicator claimed "not configured" until the (minutes-long) probe proved otherwise. The flag is now tri-state and the indicator only renders after a completed probe; a failed probe proves nothing and leaves the state unknown for the next tick.

Depends on the picker PR only for the bounded default range the probe's tests assume.

The very-long query on first view access was not the message list (which
is bounded by the default time range) but the hasSuccessfulMessages
capability probe: an UNBOUNDED sorted query over the whole audit index,
re-fired every 5 seconds by the platform-capabilities poll. It now
probes the last 7 days first, falls back to unbounded only when that
window is empty, and stops querying entirely once successful messages
have been seen — they don't un-exist.
The 'no successful audit messages' onboarding banner and dashboard card
assumed 'no messages' by default (the flag started false) and un-rendered
once the probe proved otherwise — on large stores that meant minutes of a
wrong onboarding prompt, and on every fresh session a flicker.

hasSuccessfulMessages is now tri-state: null (not yet determined),
false (a completed probe found nothing), true. While unknown the
auditing capability reports a new Checking status: the All Messages
banner renders nothing and the dashboard card shows its loading overlay.
A failed probe proves nothing about the data, so it leaves the state
unknown and the next tick retries instead of claiming 'no messages'.
@ramonsmits
ramonsmits force-pushed the ramon/audit-capability-probe branch from 9a216ca to b34c47b Compare September 7, 2026 15:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Improvement Improvement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants