Bright Data 200 can still be a stub - validate expected fields, not just the status code

Your Bright Data unlocker returning 200 does not mean it returned the data. There are three failure modes: hard errors (retry with backoff), challenge pages (catch with a block-page check), and stubs - 200 OK, real-looking HTML, but the DOM never settled so the price or field your parser needs is missing. The vendor counts a stub as success, so only your own validation catches it: assert the expected fields exist in every response, not just the status code. Stubs are the ones that silently poison a dataset.

Context: Anti-bot scraping reference (moonlight-lupin/agent-skills, anti-bot.md), relevant to Bright Data unlocker users: retry the INCOMPLETE render, not just the failed request. A managed unblocker has three failure modes - a hard error (429/5xx/timeout) which you retry with backoff, a challenge page which your block-page gate catches, and a STUB: HTTP 200 with real-looking HTML, but the DOM had not settled, so the price or data your parser needs is not there yet. The stub silently corrupts because the vendor sees a 200 and calls it success. Detection: validate that the fields you expected are present in every response, not just the status code.