Unified search: render-store readiness for getSearchEntriesResource#5242
Open
habdelra wants to merge 2 commits into
Conversation
A card rendering @context.searchResultsComponent in a prerenderable template drives getSearchEntriesResource through the render route. The render route's settle loop (#waitForRenderLoadStability) only awaits the render store's loaded() / loadGeneration, but the resource tracked its in-flight v2 search solely via an @ember/test-waiter — invisible to that loop. The html-only branch deposits nothing into the store, so nothing moved the load generation either, and the prerender could capture HTML before the search resolved: an empty result list. The resource now resolves the render store while prerendering (gated on __boxelRenderContext, like prerendered-card-search) and routes its v2 search fetch and a store.trackLoad() of every search through it. trackLoad bumps the load generation the moment a search starts and keeps the load pending until it resolves, so the settle loop waits for results before HTML capture — mirroring the v1 SearchResource. Outside a prerender this is the injected live store, unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
habdelra
commented
Jun 15, 2026
habdelra
commented
Jun 15, 2026
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a0f603619a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Contributor
There was a problem hiding this comment.
Pull request overview
Ensures v2 SearchEntriesResource participates in prerender readiness by routing its fetch + load tracking through the render store when running under __boxelRenderContext, so the render route’s settle loop waits for search results before HTML capture.
Changes:
- Update
SearchEntriesResourceto (a) use the render store during prerender and (b)trackLoad()each in-flight search to advanceloadGeneration. - Add an integration test asserting render-store load tracking + generation bump under prerender context.
- Add an acceptance prerender test covering the v2
@context.searchResultsComponentsurface in an isolated template with results present in captured HTML.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| packages/host/app/resources/search-entries.ts | Use render-store + trackLoad() during prerender so render-route readiness observes v2 searches. |
| packages/host/tests/integration/resources/search-entries-test.gts | Add deterministic integration coverage for render-store readiness wiring. |
| packages/host/tests/acceptance/prerender-search-results-test.gts | Add end-to-end prerender capture test ensuring results are present in HTML. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Contributor
The end-to-end "/render waits for the v2 search before HTML capture" behavior belongs in the realm-server prerendering suite, which drives the real prerenderer — host tests run through card-prerender and never exercise the /render route. Replace the host acceptance test with a v2 prerendering test alongside the existing live-search-fallback cases: a card renders @context.searchResultsComponent in its isolated template and prerenders with its result present, not an empty list. Keep the host integration test — it's orthogonal to the route, driving the resource directly with the prerender signal set by hand to assert it registers its search with the render store's readiness mechanism. Gate the render-store switch on `__boxelRenderContext === true` to match the prerender header / job-priority helpers, so store selection and header emission agree. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
backspace
approved these changes
Jun 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of Unify prerendered-card-search and card-search. Stacked on #5239 (retarget base to
mainonce that lands).A card that renders
@context.searchResultsComponentin a prerenderable template drivesgetSearchEntriesResourcethrough the render route. The render route's settle loop (routes/render.ts#waitForRenderLoadStability) only awaits the render store'sloaded()/loadGeneration— butSearchEntriesResourcetracked its in-flight v2 search solely via an@ember/test-waiter, which that loop never observes. The html-only result branch deposits nothing into the store, so nothing moved the load generation either, and a prerender of such a card could capture its HTML before the search resolved: an empty result list that only fills in later, in the live SPA.The resource now resolves the render store while prerendering (gated on
__boxelRenderContext, the same signalprerendered-card-searchuses) and routes its v2 search fetch and astore.trackLoad()of every search through it.trackLoadbumps the load generation the moment a search starts and keeps the load pending until it resolves, so the settle loop waits for results before HTML capture — mirroring how the v1SearchResourcealready wires render-context searches. Outside a prerender,runtimeStoreis the injected live store and behavior is unchanged.Tests
search-entries-test.gts) — the deterministic contract: under__boxelRenderContext, performing the search registers exactly one load on the render store, that load is the in-flight search, and the render store'sloadGenerationadvances. (An acceptance-level capture can't isolate this — the resource's test-waiter makesawait visitwait for the search regardless of the readiness wiring; the real puppeteer prerenderer has no such settle gate.) Verified red without thetrackLoadcall, green with it.prerender-search-results-test.gts) — end-to-end: a card renders the v2 surface in its isolated template and prerenders with both results' prerendered HTML present, not an empty list.This is a prerequisite for the codemod (CS-11439) migrating cards that render search in a
fitted/embeddedtemplate, and for the Phase 2 query/collection-field prerendered-HTML work.