Calling Actor.charge before the fetch bills for a row the run never delivers

Actor.charge and Actor.pushData are two separate awaits in the same loop body ^[5]. In the first version the charge resolved first, so the platform had a billable "detail" event on record while the fetch that produces that detail had not run ^[6]. Nothing in the published snippet links the two calls, so statement order is the only control the code has.

The corrected block is three lines. The author wrote that the fix "is boring and it belongs in every metered pipeline" ^[11], and it reads: fetch through a retry wrapper that may throw, then charge, then push ^[9]. When fetchDetailPage fails after its retries, control leaves the block before the charge line, and the buyer keeps the list row it already paid for ^[10]. "Nobody complained, because the only buyer was me," the author wrote of the run that exposed it ^[8].

The same order applies one layer up, to state. Most of these Actors have an incremental mode where a scheduled run returns only rows the buyer has not received, backed by a set of ids in a named key-value store ^[12]. Mark while scanning and the store records a delivery for every id it scanned ^[13]. The published loop calls markDelivered only when pushCharged reports that the row went out, and writes the state once at the end ^[14]. One scraper compounded it by delivering newest-first and marking as it went, so a cut-off left a hole in the middle of the timeline. It now buffers oldest-first, and that leaves the surviving state as a contiguous range ^[15].

Every Actor in the set is priced per row delivered ^[4]. The cost figures come from platform runs at 256 MB with no proxy unless stated ^[16]. The expensive case is a scraper that drives a real browser, gets past Cloudflare and loads one page per row: about $0.0046 per row, which the post puts at 460 times the cost of the same output shape from a JSON endpoint ^[17]. Divide and the JSON row lands near $0.00001 ^[18]. For that ratio to transfer, the target has to answer a plain Node fetch at 256 MB without a proxy. Several do: Meetup, Eventbrite, Kalshi, Polymarket, Himalayas, Jobicy and every European company registry return clean JSON at the right URL, which the author calls "the highest-paid ten minutes in the whole build" ^[19]. Substack's search endpoint does not. It ignores a plain fetch even with a copied user agent, needed got-scraping from the Crawlee family locally, and needed a residential proxy on the platform. The publication endpoints are fine with plain fetch ^[20].

An undelivered row is one failure mode. A wrong row is the other, and per-row pricing bills both the same. Passing limit to the Himalayas search endpoint silently returns twenty rows forever, because the listing endpoint takes a cursor and search takes page ^[23]. Meetup answers location=Berlin with events near the server's IP, a US datacenter city on a cloud run, so the Actor geocodes the city once through OpenStreetMap and sends de--Berlin instead ^[21]. Workday's board comes back only from a POST carrying { limit: 20, offset } as JSON and an Accept-Language header, while every other ATS in the set is a GET ^[22]. And a keyword filter built on includes() matched "rust" inside "trustworthy" and returned a job post that never mentioned the language. It is now a built regex with a Unicode-aware boundary that still lets c++ and node.js through ^[24].