A run can no longer crash on a page that navigates under it. If you
scripted around exit 1 from this scraper, that path is gone — the same
event now reports exit 3 or 6, with a reason.
The canary was dispatched for the first time, deliberately without a proxy
secret, and it failed. Three fixes came out of that one run.
Fixed
_count crashed the Playwright engine. A scroll batch was polling the
card count when the page navigated — Cloudflare's challenge can arrive at any
moment on this site — and Playwright raised Execution context was destroyed, most likely because of a navigation. Exit 1, a crash, where the honest
answer was "blocked". Both parity engines had guarded that call from the
start.
_scroll_to_bottom was unguarded in the same engine. Found by the check
written for the first fix, before anyone thought to look.
A feed that stopped growing because the page was REPLACED was reported as
exhausted — a COMPLETE stop reason. So a run blocked halfway would have
kept its earlier batches and called them the whole listing. All three engines
now classify the current page before concluding, and report
blocked_mid_scroll — partial, with the rows it did get.
Added
A check that every driver primitive the scroll loop drives — _count,
_page_height, _scroll_to_bottom — catches its driver's error in all three
engines, read structurally from the AST so it needs no engine library
installed. Verified by reverting both fixes: it names the engine and the
primitive each time.
572 offline checks.