Context
From a 90-day retrospective of 271 logged incidents building two production SaaS apps with Claude Code (each record has root cause + prevention + detection channel). This is a recurring pattern report; sibling reports from the same dataset are linked at the bottom.
Type of Behavior Issue
Claude made incorrect assumptions about my project (specifically: that success-shaped responses are trustworthy).
What Happened
When an upstream dependency fails politely — HTTP 200 with an empty array — Claude (and the pipelines it writes) treat it as a valid result:
- Our scraping vendor, when blocked by the target site, returns success+empty. Five pipeline layers each reported "normal" while the product silently produced nothing for days. Every alert Claude had designed hung off
catch blocks — and this failure never enters a catch. Our logged wording: "all alerting hangs off catch — which is no alerting at all."
- A separate fetch-window bug silently discarded 2/3 of candidates. Same signature: nothing thrown, nothing logged, output just quietly shrank.
When asked to investigate "no data" symptoms, Claude's default hypothesis was "there is genuinely no data," not "the source may be failing politely."
Expected Behavior
In data-pipeline contexts, empty-success from an external dependency should be treated as a hypothesis to investigate, not a result to propagate. Concretely:
- When writing pipeline code, default to recording why a result was empty (quota / blocked / genuinely none) and flagging consecutive-empty streaks.
- When verifying its own work, Claude Code could surface "this verification returned 0 rows/items" as a distinct signal instead of letting it read as a pass.
Reproducibility
Pattern-level; at least 3 major incidents in 90 days, one costing days of silent production downtime.
Model / Version / Platform
Opus (most sessions; some Sonnet) · Claude Code 2.1.235 · Anthropic API · macOS
Impact
High — silent product downtime plus real money burned on paid API calls that returned nothing.
Context
From a 90-day retrospective of 271 logged incidents building two production SaaS apps with Claude Code (each record has root cause + prevention + detection channel). This is a recurring pattern report; sibling reports from the same dataset are linked at the bottom.
Type of Behavior Issue
Claude made incorrect assumptions about my project (specifically: that success-shaped responses are trustworthy).
What Happened
When an upstream dependency fails politely — HTTP 200 with an empty array — Claude (and the pipelines it writes) treat it as a valid result:
catchblocks — and this failure never enters a catch. Our logged wording: "all alerting hangs off catch — which is no alerting at all."When asked to investigate "no data" symptoms, Claude's default hypothesis was "there is genuinely no data," not "the source may be failing politely."
Expected Behavior
In data-pipeline contexts, empty-success from an external dependency should be treated as a hypothesis to investigate, not a result to propagate. Concretely:
Reproducibility
Pattern-level; at least 3 major incidents in 90 days, one costing days of silent production downtime.
Model / Version / Platform
Opus (most sessions; some Sonnet) · Claude Code 2.1.235 · Anthropic API · macOS
Impact
High — silent product downtime plus real money burned on paid API calls that returned nothing.