Skip to content

⚡️(front) read the cached config once per page load - #629

Open
providenz wants to merge 1 commit into
mainfrom
providenz/throttle-use-config
Open

⚡️(front) read the cached config once per page load#629
providenz wants to merge 1 commit into
mainfrom
providenz/throttle-use-config

Conversation

@providenz

Copy link
Copy Markdown
Collaborator

Purpose

The application configuration is cached in browser storage and used to seed the data layer on first load. Reading it back involved a synchronous storage access plus a full parse of the payload, and that ran on every render of every component that consumes the configuration. There are around nineteen such consumers, several of which re-render continuously while a response streams, so this put avoidable blocking work on the main thread in a hot path. The parsed value is only ever used to seed the cache, so every parse after the first was discarded.

Proposal

  • Read and parse the stored configuration once per page load rather than once per render.
  • Keep the in-memory copy in step with writes, so refreshing the data layer still starts from the most recent configuration rather than whatever happened to be stored when the page loaded.
  • Add a regression test that renders several consumers across multiple renders and asserts a single storage read. It fails against the previous behaviour with fifteen reads.

Signed-off-by: Laurent Paoletti <lp@providenz.fr>
@coderabbitai

coderabbitai Bot commented Jul 27, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@providenz, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 15 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: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 89e9f5dc-bff5-4f1b-a8bd-801be5f2880c

📥 Commits

Reviewing files that changed from the base of the PR and between d9fd8f1 and 3c35784.

📒 Files selected for processing (3)
  • CHANGELOG.md
  • src/frontend/apps/conversations/src/core/config/api/__tests__/useConfig.test.tsx
  • src/frontend/apps/conversations/src/core/config/api/useConfig.tsx
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch providenz/throttle-use-config

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

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

@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant