fix: keep first fetch when shadow-DOM prerender falls back - #278
Merged
Conversation
#276 returns the parallel fetch (mode: fetch, 2xx) when page.content() is a 4xx challenge. The #277 upgrade guard only checked status, so that later fetch replaced the already-good first snapshot — including a 200 soft-block or interstitial body. Only accept a successful prerender result for the auto-mode upgrade.
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.
Bug and impact
Auto-mode shadow-DOM upgrade can replace a working first
fetchwith a later, worse 2xx body and still report success.Trigger:
fetchreturns 200 HTML that contains custom elements (shadow DOM).page.content()is a 4xx WAF/challenge page.#276falls back to the parallel fetch. That second request can also be 200 — a soft-block interstitial, a rate-limit page, or any other divergent snapshot.#277only checkedstatusCode < 400, so the later fetch overwrote the known-good first snapshot.Microlink then extracts metadata / captures from the wrong document while advertising
statusCode: 200.Root cause
#276returns{ mode: 'fetch', statusCode: 200 }when prerender itself is unusable.#277treated any 2xx retry result as a successful upgrade, not only a successful prerender.Fix
Require
prerenderResult.mode === 'prerender'before replacing the first fetch. Direct{ prerender: true }still falls back to fetch as#276intended.Validation
soft blockwhile prerender is 403 — first snapshot is kept.Note
Low Risk
Single guard in the shadow-DOM retry path plus a focused test; behavior change is narrower (keeps first fetch more often) with no auth or data-layer impact.
Overview
Fixes auto-mode shadow-DOM upgrade replacing a good first
fetchsnapshot with a worse document while still reporting success.When the prerender retry is unusable (e.g. WAF/challenge
page.content()at 4xx), inner prerender logic can fall back to a parallel fetch and return{ mode: 'fetch', statusCode: 200 }— sometimes a soft-block or divergent 2xx body. The shadow-DOM path only checkedhtmlandstatusCode < 400, so that fallback could overwrite the known-good first fetch.The upgrade now requires
prerenderResult.mode === 'prerender'before swapping in the retry result, matching the intent that only a successful prerender should replace fetch.Adds a regression test: prerender mocked as 403 while the second fetch is 200 “soft block”; the first snapshot with shadow-DOM content is kept.
Reviewed by Cursor Bugbot for commit d0a6ff1. Bugbot is set up for automated code reviews on this repo. Configure here.