The bug lives entirely in the predicate: asking `items.length > 0` only asks whether the pipeline produced rows, and every scraper in this fleet produces at least one row on purpose -- a summary object with run stats appended to the end of every dataset [5]. One resolver goes further and emits an explicit `{"resolved": false, "query": "asdfghjkl ltd"}` when it cannot match a company [6], which is a good habit for logging but still not a delivered result. The published fix filters out `_type === 'summary'` and `resolved === false`, then returns `{found: false, billed: null}` when nothing survives [7]. That works, and it is a deny-list of row types that are not results, which means it needs an edit every time a new row type appears.
The second failure removes the error channel entirely. `Actor.charge`, handed an event name that was never registered in Console, does not throw; it returns [10]. So a new Indeed tool reported `{"billed": {"event": "search_jobs_indeed", "count": 1}}` while the platform recorded `chargedEventCounts: {}` [9]. There was nothing for a try/catch to catch [10]. Ten real postings went out over residential proxy that the author pays for by the gigabyte, for free [9]. The trigger was a browser tab dying halfway through the pricing wizard [8]. Confirmation only exists on the read path: `GET /v2/acts/{id}`, look for the event in `pricingInfos`, which is what the author checked before putting the tool back in the `tools` array [11]. A revenue graph that looks better than expected just means the checking has to happen somewhere else [4].
The fourth case is a schema default. The Google Trends Actor put its residential proxy configuration under `prefill` [13]. `prefill` populates the form in the Console and does nothing else [13], so a Console run and an `apify-client` run are two different configurations of the same Actor. It cost nothing and it broke every programmatic caller for an unknown length of time [14].
Three of the four only appear when the caller is not a browser [15]. Three out of four is 75% of the failure set that a Console click-through cannot reach [16].
For any of this to be your problem, a few things have to hold. You meter per event rather than per compute-unit [17]. Your datasets carry rows your own pipeline wrote for its own purposes [5]. And your caller is an agent, which reports that it could not find anything and moves on, rather than a person staring at an empty dataset and asking for a refund [3]. That last one is the load-bearing condition. With a human on the other end, the refund request is your monitoring.
The most useful line in the post is the one where the author declines to claim a win: the startup check that would refuse to register a tool whose billing event is missing from the Actor's own `pricingInfos` is described as a hardening step not yet built, flagged as a gap [12]. The post also promises that a single check caught all four bugs [2], and the copy available to me breaks off mid-sentence in the input schema section before that check is described [19]. I cannot evaluate a check I have not read. I can say which of the two candidates I would take first: the boot failure, because it is a fixed cost paid once at startup, while the row filter is maintenance forever.
