The parser ran clean on my laptop: full catalog, prices, stock flags, all of it.
The same commit on the server gave back a catalog too. Just not the same one.
Prices were off by a few percent. Some items were missing. A few carried availability states I had never seen locally. Nothing crashed, nothing logged an error. The scraper did exactly what I wrote it to do, against a page the retailer had chosen to serve a datacenter IP rather than a home connection.
That site shaped its own response: region, currency, language, availability, and sometimes the markup itself. My machine was not a cleaner version of production. It was a different customer.
It cost me days of debugging the wrong layer (selectors, parsing, encodings) because the code was innocent and the input was quietly lying.
What I changed after that, and still do on every catalog pipeline:
I treat the environment as an input, not as ambient context. Locale, currency, declared region, request headers, egress path: pinned explicitly and asserted on, not inherited from whichever machine happens to run the job.
I keep the raw response that produced a parse, not only the parsed result. When the numbers look wrong I want to compare bytes, not theories.
And I diff each parse against the one before it. Real catalog data drifts slowly: a page served under different assumptions drifts all at once.
So "works on my machine" is seldom about the code. It is about which hidden inputs your machine supplied for free, and which ones production refuses to.
I write longer versions of these production notes on my blog, if that is your kind of reading: https://polycratia.com/c/223c85fe
If you run scrapers or catalog pipelines, something probably exposed your environment difference in the end: a data mismatch, a customer complaint, or a reconciliation that would not add up. I'm curious which one it was for you...