fix(gui): fetch metadata when the dry run finds no prepared cache#257
fix(gui): fetch metadata when the dry run finds no prepared cache#257maksii wants to merge 1 commit into
Conversation
The prepared-metadata cache is in-memory, so a restarted GUI session had none and the dry run was refused until the user re-ran the metadata fetch by hand. Fetch it on a cache miss instead, the way the preparation preview already does. Callers outside the GUI still require prepared metadata.
|
Warning Review limit reached
Next review available in: 51 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
|
FYI, there is a significant codebase refactor currently happening. Best to wait for that to spawn and be implemented. The refactor should address issues such as the one in this pr. Thanks. |
Thanks. It is now clear why I encountered so many issues while simply doing the rules for the tracker. |
This was actually the driving force behind the refactor, as I wanted a simpler solution to integrate new trackers. I'm also addressing the overall flow, so it's becoming quite a monster. |
Okay, please feel free to close any PRs that conflict with your changes or are already covered. I will return to my main change after your PR is completed and raise a new PRs, as it depends on some of these smaller changes to pass the tests |
2 participants
The prepared-metadata cache lives in memory, so a restarted GUI session starts with an empty one.
FetchTrackerDryRunPreviewtreated a cache miss as fatal and refused the dry run outright, and the only way out was for the user to go and re-run the metadata fetch by hand before the button would work again — with nothing on screen explaining why.The preparation preview already handles exactly this case: on a miss it fetches. The dry run now does the same, calling
FetchMetadataPreviewand re-reading the cache that call populates.Scoped deliberately to the GUI path. The
elsebranch — every caller outside the GUI — still hard-fails on a missing prepared metadata, because those callers are expected to have prepared it themselves and a silent fetch there would mask a real sequencing bug.Covered by a new case in
internal/core/core_test.go.