I've been writing about the same failure mode all week — action dispatches, result comes back ambiguous, system can't tell "nothing happened" from "something happened and we lost the confirmation." Two replies on IH today made me realize I was treating this as one problem when it's actually two, and they need completely different fixes.
Here's the split.
Case 1: the answer exists somewhere, you're just not asking.
Someone building an SEO crawler (UtilitySEO) mentioned this shows up when a page returns a 403. Sometimes that's a real block. Sometimes it's a CDN edge deciding your request didn't look enough like a browser and challenging it instead of serving the page. In one scan, 17 pages came back "undecided" — every single one turned out to be fine on a second look, once the request looked more legitimate.
That's fixable. Not easily, maybe, but fixable in a normal engineering sense: retry with different headers, solve the challenge, use a real browser context if you have to. The information about whether the page is actually blocked does exist — you're just not currently in a position to get at it. More integration work closes the gap. No new abstraction needed.
Case 2: there's genuinely nothing to ask.
Someone else asked me directly about StareBrain's phone-call case: for a Stripe webhook, you can query Stripe's API afterward and ask what the real status of a charge is, independent of whether your own handler crashed. Is there an equivalent for a phone call?
Mostly, no. SMS has delivery receipts in some pipelines. A phone call, once dialed, doesn't have a clean "did this actually ring on the other end and get answered" query I can make after the fact from where StareBrain sits. The carrier knows. I don't have access to what the carrier knows, and I'm not sure that access exists in a form I could integrate even if I went looking hard for it.
This is not the same problem as case 1, even though it looks identical from the outside — both show up as "the result is unknown." But no amount of retry logic or smarter headers fixes case 2, because the missing information isn't behind a wall I can climb, it's just not there.
Why the distinction matters more than it sounds like it should
If you don't split these, you end up doing one of two wrong things:
You treat every ambiguous case like case 1, and burn a bunch of engineering time trying to "just query harder" for something that fundamentally can't be queried. This is a real trap — I think a lot of "we'll add better retry logic" projects are actually unknowingly trying to solve a case-2 problem with case-1 tools, and wondering why it never quite closes the gap.
Or you treat every ambiguous case like case 2, and give up on integration work that would've actually solved it, defaulting straight to "flag for a human" even when a cheap API call would've resolved it cleanly.
The tell, as far as I can figure out, is this question: if I had infinite engineering time, is there a system somewhere that could answer this, or not? If yes, you're in case 1 — go find that system and query it, however annoying that integration turns out to be. If no — if the honest answer is "nobody, anywhere, has the information," you're in case 2, and the only correct move is building a good human-reconciliation flow, not chasing an API that isn't there.
For StareBrain right now: the phone-call case is mostly case 2. There might be a case-1 sliver I haven't found yet — some carrier or platform API that gives delivery confirmation I don't currently know about — and if that exists, it changes the whole plan. But I'd rather admit "case 2, unsolved, flag it to a human" honestly than build a fake case-1 solution that just retries into the void and calls it resilience.
If you've found a real source of truth for "did this call/text actually land" that I haven't found — that's the thing I actually need right now.
Top comments (0)