DEV Community: FlareCanary

Your Shopify discount is in the admin but missing from the API — the 2026-07 market-eligibility trap

FlareCanary — Tue, 26 May 2026 05:01:05 +0000

Shopify shipped market eligibility for discounts in the 2026-07 Admin API (announced on the changelog as "Assign discounts to specific markets," May 7, 2026). Merchants can now scope a code or automatic discount to specific markets — region, B2B company location, retail location.

That's the feature. Here's the part that doesn't show up in a release-note skim:

If you query discounts on an API version prior to 2026-07, any discount that has market eligibility set is filtered out of the response — because older versions can't represent it. This applies to both list queries and fetching a specific discount by ID.

No error. No userErrors. No deprecation header. The discount is simply not in the payload. And unlike most breaking changes, this one has no countdown — it is already live for any merchant who has touched the new market-eligibility selector in their admin (it's available on Basic plans and up). If your app is pinned to 2025-10 or 2026-01, you may be returning incomplete discount data to your users right now.

Here is the silent-fail surface we keep seeing.

1. A clean 200 with the discount missing

The app queries discounts on its pinned version:

# App pinned to API version 2026-01
query {
  discountNodes(first: 100) {
    nodes {
      id
      discount {
        ... on DiscountCodeBasic { title status }
        ... on DiscountAutomaticBasic { title status }
      }
    }
  }
}

The merchant has 12 active discounts. Three of them are scoped to the "North America" market. The query returns 9 nodes, HTTP 200, no userErrors, no extensions warning. Nothing in the response indicates three discounts were withheld.

There is no schema diff to catch at code review. The query is valid on both versions. The field set is identical. The only difference is which rows come back — and that's data, not schema, so static analysis and SDK type-checking won't flag it.

2. Fetching by ID returns `null` — which reads as "deleted"

This is the dangerous one.

query {
  discountNode(id: "gid://shopify/DiscountAutomaticNode/1099876") {
    id
  }
}

If discount 1099876 has market eligibility set and you're on a pre-2026-07 version, this returns null. Same as a discount that was deleted. Same as an ID that never existed.

A lot of integration code treats "I asked for this ID and got null" as a tombstone:

node = client.get_discount(local_record.shopify_gid)
if node is None:
    local_record.delete()   # discount removed upstream — clean up

That code now deletes a live discount from the app's own store the first time the merchant adds a market restriction to it. The discount is still working in the merchant's storefront. The app just garbage-collected its own copy because a version-filtered read looked like a deletion. This is silent data loss inside the integration, not just a missing read.

3. Sync, audit, and reconciliation jobs undercount with no signal

Anything that enumerates discounts is now working from a partial set on old versions:

Loyalty / promo-management apps that mirror discounts
"Export all active discounts" / reporting jobs
Discount-conflict checkers ("does this new code overlap an existing one?")
Reconciliation jobs that compare app state to Shopify state

They all get a 200 and a short list. The conflict checker clears a code that actually collides. The reconciliation job "heals" a discount it can't see by recreating or deleting it. The audit dashboard shows 9 active promos when there are 12. Every one of these fails toward looks correct — the worst kind, because no alert fires.

The merchant's symptom is the giveaway, and it's the exact phrase people are about to start Googling: "my discount shows in the Shopify admin but is missing from the API." It's not a bug in your sync. It's the version filter.

4. Bulk operations and anything sharing the query layer inherit the gap

bulkOperationRunQuery executes a GraphQL query at your app's configured API version. A nightly bulk export over discountNodes is exactly the "list everything" job most likely to drive downstream reporting — and it silently drops the same market-eligible discounts. Because bulk results land as a JSONL file you parse later, there's even less chance anyone notices the count is short.

If you have a webhook-driven discount cache, sanity-check what your subscription's API version actually represents before trusting it as complete. The reliable mental model: on a pre-2026-07 version, any read path that could return a market-eligible discount returns it filtered out instead.

5. After you upgrade, the inheritance rules are their own trap

Moving to 2026-07 fixes the disappearing-rows problem but introduces a correctness one if you write migration code that maps discounts to markets:

Discounts do not inherit across market types. A discount assigned to a regional market does not automatically cover a B2B company location or a retail location — those are separate market types.
Within a type, a regional assignment does cascade to sub-markets: assign to "North America" and it applies to "Canada" automatically.

Migration scripts that "assign this discount to all markets" by enumerating leaf markets and looping will either over-apply (re-adding sub-markets that already inherit) or under-apply (missing other market types entirely). Model the assignment against the type/inheritance rules, not a flat list of market IDs.

The fix

Upgrade your Admin API version to 2026-07 (or later) before treating any discount read as complete. This is the only real fix — there is no flag to opt the old version into representing market eligibility.
Until you've upgraded, treat discount reads from older versions as potentially incomplete, not authoritative. Specifically: do not drive deletes, tombstoning, or reconciliation off a null/missing discount from a pre-2026-07 version. A "not found" on an old version is ambiguous — it could be a market-eligible discount, not a deletion.
Detect your exposure with a version diff. Run the same discountNodes count against the same shop on your current version and on 2026-07. Any delta is the set of market-eligible discounts you were blind to. That number is also the size of your reconciliation-job error.
On 2026-07, filter market intentionally. Use the market context / market_ids argument on discountNodes rather than assuming the unfiltered list is global, and encode the type/sub-market inheritance rules before mapping discounts to markets.

The reason this one is worth acting on now rather than at a cutoff date: there is no cutoff. The filter is active the moment a merchant uses a feature Shopify has already shipped to every Basic-and-up store. The gap between "discount visible in admin" and "discount absent from API" opens silently, on the merchant's schedule, not yours — and the only signal is a row count that looks plausible.

FlareCanary watches your third-party APIs and SDKs for breaking changes like this one — including version-gated response filtering that returns a clean 200 with rows quietly removed — and surfaces them before they hit production. Free tier monitors 5 endpoints.

Claude Opus 4 and Sonnet 4 retire June 15 — your `claude-opus-4-0` alias is about to start failing

FlareCanary — Sat, 23 May 2026 05:01:00 +0000

On April 14, 2026, Anthropic deprecated claude-opus-4-20250514 and claude-sonnet-4-20250514. Both models retire on June 15, 2026 — about four weeks from today. After that, the Anthropic API returns errors for those snapshot IDs.

Most teams reading this already know that. What they often don't know is what else breaks on June 15, because Claude 4 is more entangled in production code than just one model ID.

Here is the silent-fail surface we keep seeing on review:

1. The `claude-opus-4-0` and `claude-sonnet-4-0` aliases retire with the snapshot

Anthropic exposes versioned aliases like claude-opus-4-0 and claude-sonnet-4-0 so callers don't have to track datestamp suffixes. The aliases are convenient — until the underlying snapshot is the one being retired.

claude-opus-4-0 resolves to claude-opus-4-20250514. That is the snapshot being retired. On June 15, the alias breaks too.

This catches teams that did due-diligence audits by searching their codebase for 20250514. The snapshot ID isn't in the code — the alias is. Grep both:

git grep -E "claude-(opus|sonnet)-4-0\b|claude-(opus|sonnet)-4-20250514"

If you find -4-0 references, those calls fail on June 15 the same as the explicit snapshot.

2. Don't confuse `4-0` with `4-1`

The Anthropic deprecation table lists only claude-opus-4-20250514 as retiring on June 15. claude-opus-4-1-20250805 — Opus 4.1 — is still active, retirement "not sooner than August 5, 2026."

Reading that quickly invites a wrong conclusion: "we're on Opus 4-point-something, we're fine."

You aren't. The retirement is specific to the bare 4 release. If your code says claude-opus-4-0, you're not on 4.1, you're on the model that retires next month.

3. Bedrock and Vertex AI run their own schedule

The retirement dates Anthropic publishes apply to the Anthropic API, the Claude Platform on AWS, and Microsoft Foundry. Partner-operated platforms — Amazon Bedrock and Vertex AI — set their own schedules.

In practice, the same alias may keep working on Bedrock past June 15 while failing against the Anthropic API. We've seen this fail one specific way:

Local dev + CI test against a Bedrock endpoint, all green.
Prod calls the Anthropic API direct, starts erroring.
The error doesn't reproduce in the dev environment because Bedrock's anthropic.claude-opus-4-v1:0 model identifier hasn't retired yet.

If you run a multi-cloud Anthropic stack, check the Bedrock and Vertex AI tables separately. Don't infer one from the other.

4. Mocked SDK tests will not catch this

A common test pattern:

@patch("anthropic.Anthropic")
def test_summarizer(mock_client):
    mock_client.return_value.messages.create.return_value = MagicMock(
        content=[MagicMock(text="summary")]
    )
    result = summarize("...")
    assert result == "summary"

The mock doesn't care which model string you pass. The string "claude-opus-4-0" is just a parameter the mock ignores. The test stays green forever — including the moment after the model is retired in production.

The fix is to push at least one integration test (gated on an API key in CI) against the live Anthropic API for each model ID your code references. If the model is retired, that test goes red. If it's mocked-only, you find out from a customer.

5. Model-router fallback configs go silent

Teams that built model-router fallbacks during the 2025 outages have configs that look like this:

models:
  primary: claude-opus-4-7
  fallback:
    - claude-opus-4-0       # <-- retires June 15
    - claude-opus-3
  on_error: ["rate_limit", "model_unavailable"]

The intent is "if 4.7 is rate-limited or unavailable, fall back to a different model." After June 15, the fallback list contains a retired model. Routing through to the fallback now produces a hard error instead of degraded service. Worse: most routers count the fallback attempt as a successful retry and never escalate.

Audit your router configs alongside your direct call sites.

6. Evals and comparison harnesses lose their baseline

If your team runs comparative evals against fixed model versions — common for regression testing prompt changes — you have a hardcoded claude-opus-4-20250514 somewhere in the eval harness. On June 15 that branch of the eval errors out. Most eval runners are written to mark errors as "skip," not "fail," because the assumption was the error is transient. After June 15, the skip is permanent and you've quietly stopped measuring against that baseline.

Capture a final round of baseline scores before June 15, snapshot the outputs, and switch the eval target to a still-active model.

The fix

Anthropic's recommended replacements (from the official deprecation table):

Retiring	Recommended replacement
`claude-opus-4-20250514` (`claude-opus-4-0`)	`claude-opus-4-7`
`claude-sonnet-4-20250514` (`claude-sonnet-4-0`)	`claude-sonnet-4-6`

API format, auth, and response structure are unchanged — only the model identifier needs to update. Pricing and capabilities differ from 4.0; do not assume the swap is cost-neutral.

If you're already doing the migration work, claude-opus-4-7 is the current top-of-line and worth jumping to rather than stopping at 4.5.

A clean migration checklist

git grep -E "claude-(opus|sonnet)-4-0\b|claude-(opus|sonnet)-4-20250514" across all repos, including infra-as-code, config files, prompts, and eval harnesses.
Check Bedrock and Vertex AI configs separately if you use them.
Audit model-router fallback chains for any 4.0 references.
Add at least one integration test per model ID that hits the live Anthropic API, gated on a CI secret. Mocked tests do not catch retirement.
Capture a final baseline of any comparative evals against the retiring models before June 15. Snapshot the outputs.
Replace claude-opus-4-0 → claude-opus-4-7, claude-sonnet-4-0 → claude-sonnet-4-6. Test response shape and cost in staging.
Re-run evals on the replacement to confirm acceptable quality on your tasks.

The fact that the API format is unchanged is what makes this dangerous. There is no schema diff to spot at code-review time. The only signal you'll get is the request failing in production at 12:00 UTC on June 15 — unless you go looking for the alias now.

FlareCanary watches your third-party APIs and SDKs for breaking changes like this one — including model retirements and alias remappings — and surfaces them before they hit production. Free tier monitors 5 endpoints.

xAI retired 8 Grok models on May 15 — the slugs still resolve, so your bill and output quality changed silently

FlareCanary — Wed, 20 May 2026 05:00:38 +0000

On May 15, 2026 at 12:00 PM PT, xAI retired eight model slugs from the Grok API:

grok-4-1-fast-reasoning
grok-4-1-fast-non-reasoning
grok-4-fast-reasoning
grok-4-fast-non-reasoning
grok-4-0709
grok-code-fast-1
grok-3
grok-imagine-image-pro

Here is the line from xAI's migration notice that makes this dangerous:

The slugs themselves continue to resolve, so you do not need to change your code to avoid breakage.

That sounds reassuring. It is the opposite of reassuring. "You do not need to change your code" is exactly why most teams didn't — and a retirement that requires no code change is a retirement that ships no signal. Nothing 404s. No SDK exception. No deploy. The same request you sent on May 14 still returns 200 on May 16. What changed is underneath the slug, and none of the usual alarms are wired to it.

Here is the silent-fail surface we keep seeing on review.

1. `grok-code-fast-1` now bills at grok-4.3 rates — and that's your highest-volume slug

grok-code-fast-1 was xAI's cheap, fast, coding-optimized model. Its entire reason to exist was running a lot of tokens for a little money — agentic coding loops, refactor passes, repo-wide edits, autocomplete backends. High call volume, low unit price. That's the slug people deliberately picked because it was cheap.

After May 15, requests to grok-code-fast-1 redirect to grok-4.3, billed at grok-4.3's rate of $1.25 per 1M input tokens and $2.50 per 1M output tokens — flagship pricing, not the fast-tier pricing you chose. The redirect is the worst possible combination: it lands hardest on the slug with the highest token throughput, and it produces no error, no warning, no changed status code. The first signal is the invoice, and the invoice arrives weeks late.

If you run agentic coding on Grok, this is not a "review next sprint" item. Your cost per run changed on May 15 and your monitoring almost certainly didn't notice, because cost-per-token isn't something most teams alert on until finance asks a question.

2. The reasoning slugs are now answering at `low` effort

The redirect is not a clean one-to-one swap. xAI maps the retired slugs onto grok-4.3 with a reduced reasoning setting:

Every retired reasoning slug (grok-4-fast-reasoning, grok-4-1-fast-reasoning) → grok-4.3 with low reasoning effort.
Every retired non-reasoning slug → grok-4.3 with none reasoning effort.

If you picked grok-4-fast-reasoning specifically because a task needed the model to think — structured extraction, multi-step tool planning, anything where you traded latency for correctness — you are now getting low effort by default. The model still answers. The answer is still well-formed JSON, still parses, still passes your schema validation. It's just measurably worse on the hard cases, and there is no field in the response that says "I thought less about this than I used to." Your eval suite is the only thing that would catch it, and only if you re-ran it after May 15 — which nobody schedules, because nothing told them to.

This is the textbook drift shape: a valid-looking response that is a correct answer to a different question than the one your code thinks it asked.

3. Cost-attribution dashboards now lie

A lot of teams tag spend by the model slug they send: a model dimension on a metrics counter, a column in a usage table, a group-by in the monthly cost rollup. Those dashboards key off the string you sent, not the model that actually ran.

Post-May-15, your dashboard still shows a tidy line item for grok-code-fast-1 at the old unit price in your own math — while xAI bills the account at grok-4.3 rates. Internal cost attribution and the actual bill have silently diverged. Every "cost per feature" or "margin per customer" number that flows from that slug is now wrong, and it will stay wrong until someone reconciles the xAI invoice against the dashboard by hand and notices the totals don't match.

4. `grok-imagine-image-pro` is a different image model now

grok-imagine-image-pro redirects to grok-imagine-image-quality. That is a different image model, not a renamed one. Anything downstream that made assumptions about the old model's output — dimensions, style, latency budget, cost per image, safety-filter behavior — is now feeding a different generator into the same pipeline with no version bump. Image pipelines are especially exposed here because the output "looks fine" to code; only a human comparing before/after notices the model changed.

5. Fallback chains lost their cheap degraded mode

Routers built during past provider incidents tend to look like this:

primary: grok-4.3
fallback:
  - grok-4-fast-non-reasoning   # cheap degraded mode
  - grok-3

The intent was: if the primary is rate-limited or down, drop to a cheaper model and keep serving. After May 15 both fallback entries resolve to grok-4.3. The "cheap degraded mode" is now full-price grok-4.3 — so the exact moment you fail over under load is the exact moment your per-request cost jumps to flagship rates, with no error and no log line saying the cheap path is gone. Incident plus silent cost blowout, stacked.

6. Pinned eval baselines now track a moving target

If you run regression evals against a fixed model slug — standard practice for catching prompt regressions — you have grok-4-fast-reasoning or similar hardcoded in the harness. That pin was the whole point: a stable baseline to diff prompt changes against.

After May 15 the pin resolves to grok-4.3 at low effort. Your "stable baseline" moved. Every prompt-change diff you run against it from now on is measuring two variables at once — your prompt edit and a model swap you didn't make — and the harness has no idea, because the slug string in the config is unchanged.

What to actually do

The migration itself is small. The detection is the hard part, because there is no schema diff to catch at review time and no error to alert on.

Grep every repo, IaC file, notebook, and prompt config for the retired slugs:

   git grep -nE "grok-(4-1-fast-(reasoning|non-reasoning)|4-fast-(reasoning|non-reasoning)|4-0709|code-fast-1|3|imagine-image-pro)"

Include eval harnesses, fallback/router configs, and cost-attribution code — not just your main call sites. Those three are where this hides.

Pin grok-4.3 explicitly and choose your reasoning effort. Don't keep riding the redirect. The redirect picks low/none for you; only an explicit grok-4.3 call with an explicit effort level (none/low/medium/high) puts the quality/cost tradeoff back in your hands.
Re-run your evals after switching, and treat any pinned-baseline eval as invalidated as of May 15. Capture a fresh baseline against an explicit model+effort you control.
Reconcile one xAI invoice line by line against your internal cost dashboard. If they don't match, your attribution is keying off the sent slug and needs to key off actual billed usage.
Add a cost-per-token alert, not just a request-count alert. This entire class of failure is invisible to availability monitoring and visible only to spend monitoring.

The reason this one is worth a sprint and not a backlog ticket: every other model retirement this year threw an error eventually. This one is engineered specifically not to. "Your code keeps working" is the failure mode, not the mitigation.

FlareCanary watches your third-party APIs and SDKs for breaking changes like this one — including model retirements, silent slug redirects, and pricing-tier remaps — and surfaces them before the invoice does. Free tier monitors 5 endpoints.

Gemini's Interactions API default flips May 26 — your interaction.outputs reads will go undefined and tool calls silently stop

FlareCanary — Mon, 18 May 2026 00:45:54 +0000

If your code calls Google's Gemini Interactions API (/v1beta/interactions), there is a short, silent window opening on May 26, 2026. On that date, Google flips the default response schema. interaction.outputs becomes interaction.steps, response_mime_type folds into a polymorphic response_format, image_config moves out of generation_config, and the streaming event names you wired listeners to all rename. The legacy schema still works if you explicitly send Api-Revision: 2026-05-07 — until June 8, 2026, when it's removed for good.

Most of these surfaces don't fail loudly. They fail by returning undefined, by ignoring a config field, or by emitting an SSE event your handler doesn't recognize. The first signal is usually a downstream consumer noticing that the model's reply is empty, or that the tool dispatch loop stopped firing, or that the generated image came back in the wrong aspect ratio.

The Timeline

May 7, 2026 — opt-in begins. New SDKs (Python ≥2.0.0, JS ≥2.0.0) ship; REST clients can opt in with Api-Revision: 2026-05-20.
May 26, 2026 — default flips. Any REST call without an Api-Revision header gets the new schema. SDKs older than 2.0.0 keep getting the legacy shape (for now).
June 8, 2026 — legacy schema removed permanently. The Api-Revision: 2026-05-07 opt-out stops working. Older SDKs that depend on outputs start breaking.

The dangerous window is May 26 → June 8: anything pinned to the legacy header keeps working, but anything calling REST without a header — most ad-hoc integrations and a lot of internal tooling — gets the new shape silently.

What Actually Changes

1. `outputs[]` → `steps[]` (the read path you almost certainly have)

Legacy response:

{
  "id": "int_123",
  "role": "model",
  "outputs": [
    { "type": "text", "text": "Why did the chicken cross the road?" }
  ]
}

New response:

{
  "id": "int_123",
  "steps": [
    {
      "type": "model_output",
      "content": [
        { "type": "text", "text": "Why did the chicken cross the road?" }
      ]
    }
  ]
}

The shape change cascades:

outputs is gone. interaction.outputs is undefined (JS) or raises KeyError (Python dict) or fails attribute access (typed clients).
The text field moves one level deeper, behind content[0]. In Python: interaction.outputs[-1].text → interaction.steps[-1].content[0].text.
A new top-level step type, user_input, appears in GET responses (full timeline). Code that iterates outputs assuming every entry is model-emitted will now also see the user's prompt as a step — fine if you filter, broken if you concatenate everything you see.

2. `response_mime_type` → polymorphic `response_format`

Legacy request for JSON output:

{
  "model": "gemini-3-flash-preview",
  "input": "Summarize this article.",
  "response_mime_type": "application/json",
  "response_format": {
    "type": "object",
    "properties": { "summary": { "type": "string" } }
  }
}

New request:

{
  "model": "gemini-3-flash-preview",
  "input": "Summarize this article.",
  "response_format": {
    "type": "text",
    "mime_type": "application/json",
    "schema": {
      "type": "object",
      "properties": { "summary": { "type": "string" } }
    }
  }
}

response_mime_type at the top level is gone — it folds into response_format.mime_type. The schema moves into response_format.schema. The discriminator that picks text vs image vs audio is response_format.type. After May 26, the server silently ignores the legacy top-level response_mime_type field; your JSON-mode call quietly stops being JSON-mode.

3. `image_config` moves out of `generation_config`

Legacy:

{
  "model": "gemini-3-flash-preview",
  "input": "Generate an image of a sunset over the ocean.",
  "generation_config": {
    "image_config": { "aspect_ratio": "1:1", "image_size": "1K" }
  }
}

New:

{
  "model": "gemini-3-flash-preview",
  "input": "Generate an image of a sunset over the ocean.",
  "response_format": {
    "type": "image",
    "mime_type": "image/jpeg",
    "aspect_ratio": "1:1",
    "image_size": "1K"
  }
}

The fields are gone from generation_config. Server-side they're not read from that location anymore. The image still generates — just at whatever the new default aspect ratio and size are. Your "always render 1:1 thumbnails" job starts shipping 16:9 widescreens with no log line to explain it.

4. Streaming SSE event names rename

Legacy	New
`interaction.start`	`interaction.created`
`content.start`	`step.start`
`content.delta`	`step.delta`
`content.stop`	`step.stop`
`interaction.complete`	`interaction.completed`
`interaction.status_update`	`interaction.in_progress`, `interaction.requires_action`, …

If you wired event listeners with a switch on event name or with EventSource handlers like es.addEventListener('content.delta', …), after May 26 those events never fire. The stream still arrives — step.delta frames pour in — but your callback isn't subscribed to them. The user-facing symptom is "the response just hangs."

5. Function calls live in `steps`, not `outputs`

Legacy tool-call response:

{
  "id": "int_001",
  "status": "requires_action",
  "outputs": [
    { "type": "function_call", "id": "fc_1", "name": "get_weather", "arguments": { "location": "Boston, MA" } }
  ]
}

New:

{
  "id": "int_001",
  "status": "requires_action",
  "steps": [
    { "type": "function_call", "id": "fc_1", "name": "get_weather", "arguments": { "location": "Boston, MA" } }
  ]
}

Tool dispatch loops typically iterate outputs, find type === "function_call" entries, invoke the handler, then submit results back. After the flip, outputs is undefined, so the loop iterates nothing, finds no function calls, returns the unaltered requires_action interaction to the caller, and the agent stalls. No exception — just an agent that "didn't decide to call a tool this turn." The same trap applies to google_search_call, google_search_result, and thought step types, all of which now live under steps.

6. The `thought` step shape changes too

Legacy thought was minimal:

{ "type": "thought", "signature": "abc123..." }

New thought carries a structured summary:

{
  "type": "thought",
  "summary": [{ "type": "text", "text": "I need to check the weather in Boston..." }],
  "signature": "abc123..."
}

Any logging or audit code reading thought.text (which never existed but was a common guess) silently gets undefined. Code that round-trips thought back to Gemini for stateless continuation now has to preserve the summary array — drop it and the model loses its scratchpad.

The Silent Surfaces

Walking through the six places this fails quietly:

Response readers — interaction.outputs[-1].text → undefined (or KeyError/AttributeError). Templated chat UIs render the empty string. Logs show "model returned no text" but the model did return text; you just stopped reading it.
JSON-mode validators — Top-level response_mime_type: "application/json" is silently ignored after May 26. The model still tries to follow the schema if you also send a response_format, but enforcement weakens. Free-form responses slip past JSON.parse on the client and crash downstream.
Image params — generation_config.image_config is silently dropped. Aspect ratio and size revert to defaults. Thumbnails come back at the wrong dimensions; layout breaks; humans complain.
Streaming listeners — addEventListener('content.delta', …) never fires. The stream finishes; your token buffer stays empty; the UI shows the spinner forever.
Tool dispatchers — function-call loops keyed on outputs[].type === 'function_call' find no calls. The agent silently no-ops on a turn the model intended to use tools.
Stateless history round-trips — passing the prior outputs array as input to the next request after May 26 → the server doesn't recognize it as a valid input shape (or worse, partially interprets it). Conversation history detaches; the model loses context with no error.

How To Detect It Before May 26

1. Opt in now and run your test suite. This is the cheapest signal. Add the header to your dev/staging environment:

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions?key=$GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Api-Revision: 2026-05-20" \
  -d '{ ... }'

…or upgrade to Python ≥2.0.0 / JS ≥2.0.0. Anything that broke in dev under the new schema will break in prod on May 26. The header buys you a controlled fire drill in staging before the default change forces it on you in production.

2. Grep for the legacy field paths. All of these are exposed:

.outputs (esp. .outputs[, .outputs[-1], outputs.length, outputs.map)
response_mime_type (anywhere in request construction)
image_config (inside generation_config blocks)
'content.delta', 'content.start', 'content.stop', 'interaction.complete', 'interaction.start' (SSE event handlers)
type === 'function_call' inside loops over outputs

Each match is a migration site. The streaming event names are the easiest to miss — a single addEventListener call buried in a chat UI can take down the whole streaming path.

3. Add a schema check on the response. Until you've migrated, log a warning if response.outputs is undefined and response.steps is present. After June 8 the legacy header stops working, so this assertion becomes a permanent canary for "are we accidentally hitting an unmigrated client path."

4. Pin Api-Revision: 2026-05-07 only as a temporary safety net. It buys you until June 8 — about two weeks past the default flip. Use it to keep prod alive while you migrate; don't use it as the long-term answer. The header stops being honored on June 8.

Why This Is Worth Paying Attention To

The same code path that ran for a year against outputs[-1].text keeps compiling, keeps passing type checks (if your types come from an older SDK), keeps returning a 200. The model itself is unchanged. The bytes on the wire are different bytes in different places. None of the usual signals — HTTP status, exception, SDK error — fire.

The pattern across all six silent surfaces is the same: a vendor moves a value to a new path, and old code reading the old path gets back a value (undefined, the default, the empty array) that's a valid answer to a different question. The wire is silent because the language is silent: undefined is a real JS value; an empty array is a real iteration; the default aspect ratio is a real image.

If you run anything on Gemini's Interactions API, the cheapest move you can make right now is to add the Api-Revision: 2026-05-20 header in staging and let the tests find what's exposed. However many days are left before May 26, spending them on a controlled staging drill beats discovering this from a confused user report after the default flips.

Notion's API Now Caps Pagination at 10,000 Results — Your 'Fetch All Rows' Sync Is Silently Truncating

FlareCanary — Wed, 13 May 2026 04:04:04 +0000

If you have a Notion integration that "fetches all the rows in this database" — a sync job, an export, a reporting pipeline — it may have started returning incomplete data without throwing anything. As of an early-2026 API change, Notion's paginated query and list endpoints enforce a hard 10,000-result maximum pagination depth. Past that point you don't get an error. You get a 200 OK, no next_cursor, and a new field telling you the result set was truncated — a field most existing code has never heard of and doesn't check.

So the loop terminates normally, the caller treats the partial set as the whole set, and everything downstream — the warehouse table, the dashboard, the "we synced N records" log line — is quietly wrong for every database with more than 10k matching rows.

What Actually Changed

The classic Notion pagination contract was: call the endpoint, read results, if has_more is true call again with start_cursor: next_cursor, repeat until has_more is false. That contract still holds — for the first 10,000 results.

Once a paginated query would cross the 10,000-result boundary, Notion stops the cursor walk and returns a response shaped like this:

{
  "object": "list",
  "results": [ /* ...the last page within the 10k window... */ ],
  "next_cursor": null,
  "has_more": false,
  "request_status": {
    "type": "incomplete",
    "incomplete_reason": "query_result_limit_reached"
  }
}

The tell is request_status. On a normal, fully-paginated response it's either absent or "type": "complete". On a truncated one it's "type": "incomplete" with incomplete_reason: "query_result_limit_reached". Notice what isn't different: has_more is false (just like a real end-of-results), next_cursor is null (just like a real end-of-results), the HTTP status is 200, and the results array is a perfectly valid array of perfectly valid pages. Nothing about the response trips an exception, a schema validator, or an HTTP-status check.

This applies to the paginated endpoints that can match large numbers of objects — database/data-source queries, and the list endpoints (users, comments, block children, search) — anywhere a single logical query could exceed 10k results.

Why This Is a Silent Failure, Not a Loud One

Walk through what each layer of a typical integration sees:

The pagination loop: while (response.has_more) { ... }. On a truncated response has_more is false, so the loop exits cleanly on the first iteration that hits the cap. From the loop's perspective this is indistinguishable from "we reached the last page." No retry, no warning.
The SDK: the official @notionhq/client (and the auto-paginating helpers built on it, like iteratePaginatedAPI) follow the same has_more/next_cursor contract. They stop when the cursor runs out. They don't inspect request_status and they don't throw — there's nothing to throw on; the server returned a valid 200.
Schema validation: if you validate the response, request_status is an additive field. A truncated response is still a structurally valid list response. Strict validators that reject unknown fields might trip — but most don't, and even then the error says "unexpected field," not "your data is incomplete."
Your "rows synced" metric: it logs however many rows came back. 10,000 is a plausible-looking number. Nobody alerts on "synced exactly 10,000 records" because that's not obviously wrong.
The data consumer: the warehouse table, the BI dashboard, the downstream API. It sees a smaller-than-expected dataset and has no way to know whether that's because rows were deleted in Notion or because the sync truncated. It renders. It looks fine.

The first real signal is usually a human: someone notices a record that exists in Notion isn't in the report, files a "data is stale" ticket, and a few hours of debugging later you find the sync has been silently capped for weeks.

Who's Exposed

Database-to-warehouse / database-to-spreadsheet sync tools pulling large Notion databases (project trackers, CRMs, content calendars, issue logs that have grown over years).
Backup and export jobs that walk every row of every database.
Internal dashboards and reporting pipelines that re-query a big database on a schedule.
Migration scripts moving content out of Notion — the worst case, because you run it once, it "succeeds," you decommission the source, and you don't discover the missing 30% until much later.
Anything using iteratePaginatedAPI or a hand-rolled has_more loop against a query that returns more than 10k objects.

If your databases are all comfortably under 10k matching rows for every query you run, you're fine — for now. The risk is the database that crosses the line six months from now, on a code path nobody's looked at since it was written.

How To Detect It

1. Check request_status on every paginated response. This is the actual fix. Anywhere you loop on has_more, also look at request_status:

const { Client, isFullPage } = require("@notionhq/client");
const notion = new Client({ auth: process.env.NOTION_TOKEN });

async function queryAllRows(dataSourceId, filter) {
  const rows = [];
  let cursor = undefined;

  while (true) {
    const res = await notion.dataSources.query({
      data_source_id: dataSourceId,
      filter,
      start_cursor: cursor,
      page_size: 100,
    });

    rows.push(...res.results);

    // The new part: detect truncation explicitly.
    if (res.request_status?.type === "incomplete") {
      throw new Error(
        `Notion query truncated: ${res.request_status.incomplete_reason}. ` +
        `Got ${rows.length} rows; result set exceeds the 10,000 pagination cap. ` +
        `Narrow the query with a more selective filter or partition by a property range.`
      );
    }

    if (!res.has_more) break;
    cursor = res.next_cursor;
  }

  return rows;
}

Throwing is the right default for a sync job: a loud failure you can see beats a quiet truncation you can't. If you'd rather degrade gracefully, at minimum increment a metric and log a warning with the row count — don't let incomplete pass unobserved.

2. Re-architect queries that legitimately exceed 10k. The cap is per query, not per database. If a database genuinely has more than 10,000 rows you care about, partition the query: filter by a date range, a status, a created-time window, or an alphabetical slice of a title property, and walk each partition separately. Each partition's pagination still has to stay under 10k, so size your partitions accordingly.

3. Add a cross-check on row counts. If you know roughly how many rows a database should have (or you can get a count another way), assert that your sync pulled within tolerance of it. A sync that returns exactly 10,000 rows when you expected ~14,000 should page someone.

4. Search your codebase for the patterns that are exposed. Grep for has_more, next_cursor, iteratePaginatedAPI, start_cursor. Every match against a Notion query is a place to add the request_status check. If you find the string query_result_limit_reached showing up in logs you didn't write that handler for, it's already happening.

The Pattern

This is the same shape as a lot of recent API changes: a vendor adds a limit, communicates it as a new field rather than a new error, and the failure mode lands in the gap between "the response is structurally valid" and "the data is actually complete." HTTP-status checks miss it. Schema validators miss it. SDKs that only know the old has_more contract miss it. The only thing that catches it is code — or monitoring — that knows the new field exists and treats incomplete as the alarm it is.

If you run integrations against third-party APIs, this is worth a standing habit: when a provider adds a status/result-metadata field to a response you already parse, assume there's a silent-failure path hiding behind it, and go check what your code does when that field says "incomplete."

Supabase's Management API OAuth Endpoint Switches From 201 to 200 on May 26 — Here's What Silently Breaks

FlareCanary — Mon, 11 May 2026 04:08:07 +0000

On May 26, 2026, the OAuth token exchange endpoint for Supabase's Management API — https://api.supabase.com/v1/oauth/token — will stop returning 201 Created on success and start returning 200 OK. Same body, same fields, same access tokens. Just a different number on the status line.

Supabase's announcement is short and accurate: most clients won't notice, because they check for a 2XX success range. The libraries it calls out by name (axios, the Fetch API, MCP TypeScript SDK, Vercel AI SDK) all do that. So if you're using supabase-management-js or any other 2XX-range-aware HTTP client, you're done — go read something else.

The teams that will notice are the ones that wrote their own token-exchange handler and put if (response.status === 201) somewhere on the success path. Or assert resp.status_code == 201 in a test. Or a log filter that only counts 201 as a successful token exchange. Those clients will silently misroute a successful response to the error branch starting May 26.

This article is about why that misrouting is quieter than it looks, and where the second-order damage lands.

What Actually Changes

The endpoint is POST https://api.supabase.com/v1/oauth/token, used by third-party Supabase integrations to exchange an authorization code for an access token, and to refresh those tokens later. It's a standard OAuth 2.1 token endpoint — form-encoded request, JSON response with access_token, refresh_token, token_type, expires_in, scope.

Today:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "access_token": "sbp_v0_...",
  "token_type": "bearer",
  "expires_in": 3600,
  "refresh_token": "sbp_refresh_v0_...",
  "scope": "rest projects.read",
  "token_type": "bearer"
}

After May 26:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_token": "sbp_v0_...",
  "token_type": "bearer",
  "expires_in": 3600,
  "refresh_token": "sbp_refresh_v0_...",
  "scope": "rest projects.read"
}

The body doesn't move. No headers change. The rationale Supabase gives is direct: OAuth 2.1 Section 3.2.3 mandates 200 from token endpoints, and "Returning 201 is non-compliant and has caused token exchange failures with some strict OAuth clients."

In other words, the fix has been making something silently fail for strict-spec clients. The migration moves the silent failure to the lax-spec clients on May 26. There is no version of this where nobody breaks; Supabase is choosing the side of the spec.

The Four Quiet Surfaces

Surface 1: Strict-equality status checks misroute success into the error branch.

The classic shape is:

const resp = await fetch('https://api.supabase.com/v1/oauth/token', {...});
if (resp.status === 201) {
  const tokens = await resp.json();
  await db.saveTokens(userId, tokens);
  return { ok: true };
}
// Otherwise: log and return an error
console.error('OAuth token exchange failed', resp.status);
return { ok: false };

On May 26, this code starts logging "OAuth token exchange failed 200" and returning { ok: false } — after Supabase has already minted a valid access token and rotated the authorization code. The auth code is single-use. The success branch never ran. The tokens never got saved. The user sees "we couldn't connect your Supabase account," tries again, and on the retry, the original auth code has already been consumed — they get a fresh OAuth flow but the integration looks flaky.

The failure mode is the worst of both worlds: it costs you a successful authorization (the code is burned) and it presents to the user as a generic connection failure.

Surface 2: Test assertions silently flip green-to-red — but only on CI, not locally.

def test_oauth_token_exchange():
    resp = oauth_client.exchange_code(test_auth_code)
    assert resp.status_code == 201  # <-- the bomb
    assert "access_token" in resp.json()

Pre-May 26, this test passes against a recorded fixture, against staging, against your local mock server. It also passes against production. After May 26, it fails against production only. The integration tests in CI start failing on the 201 assertion line — but only the ones that hit real Supabase. Mocked tests, snapshot tests, and stubbed tests all keep passing because the fixtures still encode the old behavior.

This is the silent-in-CI shape that hits hardest: the test suite is louder than the production code (CI starts failing) while the production code is quieter than it should be (running customers hit token errors and you have to triangulate why). Teams that run only mocked tests on PRs (and only run real integrations nightly) might not notice until the nightly fires.

The fix is the same as the production fix — change == 201 to < 300 or in range(200, 300) — but it needs to happen in the test fixtures and the snapshot files too.

Surface 3: Authorization-code reuse on retry burns the flow.

This is the second-order one and it's subtle. OAuth 2.1 authorization codes are single-use; the spec is strict. If a strict-equality check misroutes the 200 success into a retry path that re-POSTs the same code to /v1/oauth/token, the second request will fail (the code was already consumed). The integration logs the second failure, surfaces a generic error to the user, and may emit a stack trace pointing at the retry call site — making the root cause look like "Supabase rejected our authorization code" instead of "our success handler is checking for the wrong status code."

If your client has automatic retry-on-non-2XX-but-treat-201-as-success logic anywhere (Polly, Tenacity, axios-retry with a custom predicate, a hand-rolled retryer that treats 200 as an unexpected status), this is the shape you'll see: the first exchange succeeded; the retry exhausted the code; the user sees "OAuth flow failed."

The Supabase API will respond to the doomed retry with a 400 and { "error": "invalid_grant", "error_description": "Authorization code has been used" } — searching that string from a confused engineer's perspective is the path back. (If you only find this article after May 26, that error string is the canonical post-mortem hook.)

Surface 4: Observability and metrics start undercounting successful exchanges.

Three patterns to grep for in your monitoring code:

Log filters keyed on 201. where status_code = 201 in your Splunk/Datadog query for "successful Supabase auth" silently drops to zero on May 26. The dashboard reads as "outage," but nothing broke — the queries did.
Webhook/audit logging that records only specific status codes. Some custom audit pipelines emit different events for 201 Created vs other 2XX. After May 26, the created event stream stops; the audit log shows nothing where there should be daily entries.
Alerting rules that fire on "no 201 in the last hour." Pages on-call when the underlying system is healthy.

The cure here is the same shape as the test fix: replace status-equality with status-range, regenerate dashboards, update audit-event mappings. The work is small if you grep for it; the work is bottomless if you wait for the dashboards to tell you.

Who Should Audit Right Now

Three groups, ranked by likely impact:

Anyone building a Supabase integration from scratch. If you wrote your own OAuth client (because you needed something supabase-management-js didn't expose, or you're in a language without a maintained Supabase library, or you wanted to control the token-cache layer yourself), search your codebase for the literal 201 near anything OAuth-related.
Anyone shipping a Supabase integration in a typed language with overly-specific status types. The pattern looks like enum Response { Created(Tokens), ... } or case .created(let body): ... — Swift, Rust, Kotlin, Scala. Strict status-typing is what bites this surface hardest; the compiler can't help you, but a grep for the literal 201 or the language-specific created enum variant will.
Anyone whose CI pipeline does real-network integration tests against api.supabase.com. Even if the production code is fine, the test fixtures might pin 201 and turn the build red on May 26 for no production-impacting reason.

The Migration Is Trivial; The Audit Is the Work

The actual code change is a one-liner per call site:

- if (resp.status === 201) {
+ if (resp.ok) {  // covers 200, 201, and anything else in 2XX

Or, in Python:

- if resp.status_code == 201:
+ if 200 <= resp.status_code < 300:

Or the more spec-precise version that matches OAuth 2.1's expectations:

- if resp.status_code == 201:
+ if resp.status_code == 200:

The first form is the most forgiving and the one Supabase's announcement recommends. The third is the most spec-faithful and breaks again only if Supabase migrates to a different success code in the future (which they won't — 200 is the spec).

Once the production code is fixed, sweep:

Unit tests asserting on response status
Snapshot tests / contract tests with hardcoded 201 literals
Logging templates with "status=201" formatted in
Monitoring queries grouped or filtered by status code
Audit-log producers emitting different event types per 2XX status

If you've got grep, this is a 20-minute job. If you don't, it's the kind of thing that surfaces in a frantic Slack message four days after May 26.

The Pattern, Beyond Supabase

Status-code compliance migrations are a recurring shape: an API was returning the wrong-but-working status, strict spec compliance forces a change, the change is technically harmless, and the only code that breaks is the code that violated the contract twice — once by depending on a specific status code, and once by treating the wrong status code as canonical. The same kind of move shows up periodically in Stripe API version changes, in GitHub's REST API breaking changes, in payment provider response normalizations.

What's interesting from a runtime-monitoring angle is that the affected systems are exactly the ones with the least observability — they're the hand-rolled clients, the custom integrations, the test fixtures that nobody touches. The libraries with strong status-code abstractions absorb the change silently, which is the right behavior; the systems without those abstractions absorb it as silent failure.

This is the same pattern we see across other "minor" API changes that turn into customer-impacting bugs weeks later: the migration is two lines of code, but the audit is across every place anyone touched the API surface — and most teams don't have a single inventory of those places. That's the lookup problem that FlareCanary exists to solve at the response-shape layer: watch the API, catch the structural change, route the alert to whoever's name is on the integration. The body isn't changing on May 26, so a content monitor wouldn't catch this one — but a status-code or header diff would.

If you're shipping a Supabase Management API integration and 201 is anywhere in your codebase, this is the moment to find it. Two weeks of runway, a one-line fix, and a quiet failure mode if you wait.

If you're maintaining a Supabase OAuth integration and find this article while staring at an invalid_grant error you don't remember writing, the fix is at the success-handler call site, not at the retry layer. Drop a comment if the failure shape looked different from what I described — the more shapes we catalog the better.

AEM Cloud Stops Receiving Adobe Updates June 11 If You Use Deprecated APIs — Here's the List and How to Tell

FlareCanary — Mon, 11 May 2026 04:02:00 +0000

On June 11, 2026, AEM Cloud Service environments still running deprecated Java APIs stop receiving Adobe release updates. They'll keep serving traffic. They'll keep handling authoring. They just go silently un-patched — no security fixes, no bug fixes, no platform updates — because Adobe will hold those updates back from environments that haven't successfully completed a pipeline run on the new API surface.

That's the part that matters and that's the part most teams will miss. Not because Adobe didn't tell anyone, but because the way Adobe rolled this out has at least four surfaces where a team can quietly walk past the warnings.

The Escalation, In Adobe's Own Words

Pulled from Adobe's Deprecated and Removed Features page:

Date	What Adobe does
Jan 26, 2026	"Actions Center notification emails are sent as a reminder to remove usage of these APIs, if a pipeline has been recently executed."
Feb 26, 2026	Cloud Manager pipelines using deprecated APIs pause during the Code Quality step. A Deployment Manager, Project Manager, or Business Owner can override and proceed.
Apr 14, 2026	Cloud Manager pipelines fail during the Code Quality step. Deployments blocked until the deprecated API usage is removed.
May 4, 2026	Cutoff: "If the updates are not made by May 4th, you will no longer receive AEM version updates" — until a successful fullstack pipeline run lands.
Jun 11, 2026	"Environments still using deprecated APIs will not receive critical Adobe release updates and are not subject to Adobe's standard commitments around performance and availability."

If you read that progression closely, the failure mode at each step is different — and that's where teams lose track.

The Four Quiet Surfaces

Surface 1: The notification email assumes you've been deploying. The Jan 26 email goes to environments where a pipeline "has been recently executed." A long-tail production environment that's been stable for six months — the one running an internal portal, a partner microsite, a staging environment kept around for a single QA flow — never gets the email. The team that owns it doesn't know anything is wrong until June.

Surface 2: The February pause is overridable. Code Quality flags deprecated API usage. The pipeline pauses. A Deployment Manager / Project Manager / Business Owner with the right role can click "override and proceed." Under release pressure (a critical fix, a marketing deadline, an end-of-quarter launch), that override is going to get clicked. The override doesn't fix anything — it just lets the deploy through, and the deprecated APIs stay in the environment. The pipeline emails the override-approver, but the actual engineer who needs to migrate the code might never see it.

Surface 3: April failures are deploy-time, not runtime. When April 14 hits and pipelines start failing the Code Quality step, your running AEM environment doesn't change. It keeps serving requests. Authors keep authoring. The breakage is in your ability to deploy new code. If your team isn't shipping much (a maintenance phase, a feature freeze, a project paused for re-org), the pipeline failures don't fire until someone tries to ship — which might be weeks after the deadline. By then May 4 has passed and your environment is no longer receiving Adobe updates either.

Surface 4: June 11 is the quietest failure of the four. Your environment doesn't crash. Pages don't break. URLs don't 404. Adobe simply stops applying platform updates. Days later, weeks later, the next CVE drops on a dependency Adobe usually patches for you, and your environment doesn't get the fix. Teams typically discover this during the next security audit, not at the moment of failure.

The Actual Deprecated API List

This is the part most blog posts hand-wave. Adobe publishes the list at the public Deprecated and Removed Features page (no paywall, despite what some second-hand summaries imply), and the aem-sdk-api javadoc carries the per-class @Deprecated markers.

Here's the cohort that's in the Feb 26 / Jun 11 wave, weighted by what's most likely to actually be in your codebase:

Package family	Why it's deprecated	Replacement
`com.google.common.*` (Guava)	Adobe is removing the Guava export from the AEM platform classpath	JDK collections / Apache Commons
`org.apache.felix.http.whiteboard`	Replaced by the standard OSGi spec	`org.osgi.service.http.whiteboard`
`org.eclipse.jetty.*` (24 sub-packages)	Adobe runs its own HTTP layer on AEMaaCS	OSGi Http Whiteboard
`org.apache.felix.webconsole`	Web console is platform-managed on AEMaaCS — apps shouldn't bundle it	(Remove the dependency)
`org.slf4j.spi`, `org.slf4j.event`, `org.apache.log4j`	Logging is platform-managed; old SLF4J / Log4J 1.x APIs are out	SLF4J 2.x public API or Log4J 2.x
`ch.qos.logback.*`	Same — platform owns logging	SLF4J
`org.apache.sling.commons.auth`	Replaced upstream	Sling Auth Core / Auth Core SPI
`com.mongodb.*` (40+ packages)	Mongo isn't supported on AEMaaCS	Remove — use AEM-native repository
`com.drew` (metadata-extractor)	Adobe-managed asset pipeline	Use AEM Assets APIs
`org.apache.jackrabbit.oak.plugins.memory`	Internal Oak — never was public API	Public Oak API
`org.apache.cocoon.xml`, `org.apache.abdera.*`	Retired upstream projects	Replace with current libs

Top single-team breakers, ranked by my read of likely incidence:

Guava (com.google.common.*). Pulled in transitively by countless dependencies — older versions of ACS AEM Commons, older versions of HTL helpers, internal utilities written before the JDK collections caught up. Searching across an AEM monorepo for import com.google.common will usually surface dozens of hits in legitimate utility code.
Jetty (org.eclipse.jetty.*). Direct usage is rare, but bundled servlet adapters, embedded test harnesses, and old OSGi HTTP service consumers pick it up.
Logback (ch.qos.logback.*). Older custom appenders, especially those written before AEM 6.5, often reach into Logback specifics.
Apache Felix Web Console. Apps that exposed custom plugins to /system/console are the affected ones.

There's a longer-runway extended cohort (org.bson.*, org.apache.tika.* (80+ packages), org.apache.commons.lang → Lang3, org.apache.commons.collections → Collections4) that isn't in the Feb 26 wave but is queued up. If you're auditing now, audit those too — you'll save a second sweep.

How to Actually Find Your Usage

Adobe ships the AEM Analyser Maven Plugin (com.adobe.aem:aemanalyser-maven-plugin, current as of v1.6.16+). Run locally before you let CI surprise you:

mvn clean verify -pl all

The output line you care about looks like:

[WARNING] Usage of deprecated package found : org.apache.commons.lang : Commons Lang 2 is in maintenance mode. Commons Lang 3 should be used instead.

Adobe's own guidance is to "treat analyzer warnings as future pipeline failures." That's the right framing. Anything the plugin flags today as a warning will be a build failure on April 14.

For environments where you can't easily run Maven locally — partner CI, infrastructure-as-code-only teams — the Cloud Manager Artifact Preparation step logs an "Analyser warnings have been found" line. If you see that in your build logs and you've been ignoring it, this is the moment to stop ignoring it.

What Happens at the Pipeline Level When You Don't Migrate

The Code Quality step on April 14+ produces something like this:

[ERROR] Build step failed with the following message:
  Code Quality - The following deprecated APIs are in use:
    org.apache.felix.http.whiteboard.HttpWhiteboardConstants  (3 occurrences in com.example.aem.servlets)
    com.google.common.collect.ImmutableList                   (47 occurrences across 12 modules)
  Deployment is blocked. Migrate these APIs and re-run the pipeline.

That's the loud surface. The quiet surface is what happens in the AEM environment itself when you don't:

Bundle resolution succeeds today because the deprecated packages still resolve from the platform.
Eventually (release-by-release), Adobe will stop exporting some of these packages from the AEM platform's Export-Package. When that lands, your bundle goes into Installed-but-unresolved state.
AEM will keep running. Your bundle will be inactive. The components that depend on it will fail to render — but only the affected paths. Customers see broken pages on specific URLs, not site-wide outages. Detection lag is high.

Migration: What's Actually Drop-In and What's Not

From	To	Drop-in?
Guava `ImmutableList.of(...)`	`List.of(...)` (JDK 9+)	Mostly. `Collectors.toUnmodifiableList()` for streams.
Guava `Strings.isNullOrEmpty`	`s == null \	\
Guava {% raw %}`Maps.newHashMap()`	`new HashMap<>()`	Yes.
Guava `Cache`	Caffeine	No — different API surface; refactor required.
Apache Commons Lang 2	Lang 3	No — package change `org.apache.commons.lang` → `org.apache.commons.lang3`. Mass import rewrite.
`org.apache.felix.http.whiteboard`	`org.osgi.service.http.whiteboard`	No — both annotation-based and programmatic registration shapes change.
`ch.qos.logback.*` direct use	SLF4J	No if you're using Logback-specific features (encoders, custom appenders).
SLF4J 1.x SPI	SLF4J 2.x	No — `LoggerFactory.getLogger()` works the same, but provider/MDC SPIs changed.

What to Google If You're Already Past the Cliff

If you only find this article after June 11, the symptoms in your environment look like:

Cloud Manager Actions Center: "AEM version update paused" or "environment is no longer receiving AEM updates."
Pipeline failure: "Build step failed: Code Quality - The following deprecated APIs are in use" (this is the April 14 onwards mode).
Bundle resolution failure log lines referencing com.google.common, org.eclipse.jetty.*, ch.qos.logback, or org.apache.felix.http.whiteboard.
Custom servlets returning 404 where they used to return 200 (Whiteboard registration silently dropped).
Logging output reduced or empty for components that wired Logback directly.

The fix path is the same regardless of when you discover it: run the Analyser, fix the flagged usages, ship a successful pipeline run, regain platform updates. Cloud Manager picks back up automatically.

The Pattern, Beyond AEM

This release shape — multi-step escalation from email, to pause, to override, to fail, to silent un-patching — isn't unique to Adobe. It's the same pattern you see in Microsoft 365 Message Center retirements, in long Salesforce sunset cycles, in Stripe API version moves with brownouts.

What's interesting about it from a monitoring angle is that every surface in the escalation is silent-fail to some part of the team. The Jan email reaches deploy-active environments only. The Feb pause is overridable by approver roles that may not be the migration owner. The Apr failure is deploy-time, not runtime. The May/June cutoffs are about future updates, not current functionality. There is no single point at which a team is forced to know.

The only durable defense is to be watching for this pattern continuously — analyzer output in CI, deprecated-API counts trending over time, the Actions Center for environments that haven't deployed recently. It's the same observation that makes API response-shape monitoring useful at the runtime layer: you can't trust the changelog to reach the engineer who needs to act, and you can't trust the build to fail in the right place at the right time. Some layer needs to be watching, on a schedule, with alerts that route to the people who'd actually do the migration.

That's the work I've been doing on the runtime side at FlareCanary — watching API response shapes and flagging structural drift before dashboards go empty. The build-time analog for AEM is already in your tree (the Adobe Analyser plugin); the question is whether anyone is looking at the warnings.

If you're an AEMaaCS team and June 11 is on your calendar with a question mark next to it, run mvn clean verify against the latest aemanalyser plugin tonight. Anything red is a deploy block on April 14 — which is closer than it sounds.

If you've already hit one of these on a real environment — especially the override-and-forget path or the long-tail-environment path where you got no email — I'd genuinely like to compare notes. Drop a comment.

Cloudflare TypeScript SDK v6 Made 133 Methods Return null and Empty Bodies Return undefined — Here's What Broke

FlareCanary — Sun, 10 May 2026 04:09:04 +0000

On April 30, 2026, Cloudflare shipped cloudflare-typescript v6.0.0. The release notes call it a "major version" with "breaking changes to the generated API surface" — accurate but understated. Two specific changes in the SDK infrastructure section will silently break code that compiled and tested fine on v5:

133 methods now return null instead of a typed response object. Most are deletes, but the list also includes some create, update, and get operations across accounts, cache, d1, filters, firewall, hyperdrive, iam, kv, logpush, logs, r2, stream, workers, zero-trust, and zones.
Responses with content-length: 0 now return undefined instead of attempting to parse the body. Anywhere the server returned an empty 200/204, the SDK used to hand you back an empty object. Now you get undefined.

Both are documented. Neither is loud at runtime. If you npm install cloudflare@latest (or have Dependabot auto-bumping you), the surface looks the same — same import paths, same method names, same TypeScript types in your IDE. The runtime objects are just shaped differently than before.

What Actually Changed

Direct from the v6.0.0 changelog:

Empty response handling: Responses with content-length: 0 now return undefined instead of attempting to parse the body. This may affect code that expected an empty object or null.

133 methods now return null instead of a typed response object. This affects delete operations, some create/update operations, and several get operations.

The example they give:

// Before (v5)
const result: AccountDeleteResponse = await client.accounts.delete({ ... });

// After (v6)
const result: null = await client.accounts.delete({ ... });

Plus a third change worth flagging:

Retry-After handling changed: The SDK now respects any server-specified Retry-After value for rate-limited requests. Previously, values over 60 seconds were ignored and a default backoff was used instead.

If Cloudflare hands you a Retry-After: 3600 during an incident, your client now actually waits an hour. Pre-v6 it would have ignored anything over 60s and used the default backoff. CI and production code paths that assumed bounded retries can now hang.

The Silent-Fail Surfaces

This release is interesting because the failures don't look like failures.

Surface 1 — result.id on a deleted resource. Common pattern across Cloudflare-using codebases:

const deleted = await client.r2.buckets.delete(bucketName, { account_id });
console.log(`Deleted bucket ${deleted.id}`);
// v5: logs the bucket id
// v6: TypeError: Cannot read properties of null (reading 'id')

Loud-ish — you'll see this in logs eventually. But if it's behind an error boundary, in a try/catch that swallows, or in a fire-and-forget cleanup path, it's quiet.

Surface 2 — if (result) truthiness checks for success confirmation.

const result = await client.kv.namespaces.delete(namespaceId, { account_id });
if (result) {
  await markSuccess(namespaceId);
} else {
  await markFailure(namespaceId);
  await alert("KV delete failed");
}

On v5, result was a typed response object — truthy. On v6, result is null — falsy. Every successful KV delete now flows down the failure branch. Your alerting fires on green operations. Your dashboard says everything's broken. Your runbook says "we just deleted half our namespaces by mistake" — but actually no, the deletes succeeded, your detection is just inverted.

Surface 3 — empty-body responses in retry/idempotency code.

A bunch of Cloudflare endpoints reply 200 with content-length: 0 for idempotent no-op operations. Pre-v6 the SDK gave you {}. Post-v6, undefined. Code like:

const response = await client.zones.purgeCache(zoneId, { files });
const purgedAt = response.timestamp ?? new Date().toISOString();
// v5: response is {}, response.timestamp is undefined, fallback fires.
// v6: response is undefined, response.timestamp throws.

If you destructure or chain off the response without optional-chaining, this surfaces as Cannot read properties of undefined (reading 'timestamp'). If you use response?.timestamp, it works on both — but lots of older Cloudflare SDK code pre-dates the optional-chaining habit.

Surface 4 — Retry-After unbounded waits.

If your job runner has a hard timeout (CI minute caps, Lambda 15-minute ceiling, Cloudflare Workers' 30-second CPU budget) and Cloudflare returns Retry-After: 1800 during a degraded period, v6 will park your call for 30 minutes. The job times out, the alert is "function execution exceeded timeout" — which sends ops down a totally wrong rabbit hole. The fix is to set a max retry delay in your client config, but the v5 client did that for you implicitly.

Surface 5 — CLOUDFLARE_API_TOKEN="" is now unset.

// .env loader sets CLOUDFLARE_API_TOKEN to empty string when the var is missing-but-defined
// v5: SDK uses the empty string, the API rejects with 401 (loud).
// v6: SDK treats it as unset, falls back to "no auth", request fires unauthenticated.

Same outcome — 401 from the API — but the path through the SDK is different, and any code that introspected the client to see "is auth configured" now reports "not configured" where it used to report "configured but empty."

Why TypeScript Doesn't Save You

The interesting bit: TypeScript does save you, but only on a fresh codebase. If you upgrade in place:

The result: null change is a type narrowing. Code that types result as AccountDeleteResponse | null and then accesses result.id is a compile error in strict mode. But lots of consumers don't pin the response type at all — they let inference do the work. Inference picks up the new null type. Code that was result.id is still result.id after recompile, but now it's a type error.
Most teams handle the type error with the path of least resistance: result?.id or (result as any).id. Once that lands, the runtime behavior is "log undefined" or "throw on a tighter access" — and the underlying bug (treating success as failure, treating empty body as parsed object) is still there.
The content-length: 0 → undefined change has no type change to flag it. The return type of purgeCache is the same. The runtime value silently shifts from {} to undefined. Nothing in tsc will catch it.

The Retry-After change has no surface in the type system at all. It's a behavioral change inside the retry interceptor.

How to Find If You're Affected

1. Pin or unpin deliberately. If you're on v5.x and not ready to audit, pin cloudflare@^5. If you've already moved to v6, do the audit — don't sit in the middle. Dependabot/Renovate will not flag this for you because the major version bump is "expected breaking change."

2. Grep for the patterns. In your repo:

# Likely-broken: accessing fields on results from likely-now-null methods
rg "client\.\w+\.delete\(.*?\)\.\w+" --type ts
rg "(result|response|deleted)\.(id|name|success)" --type ts
# Truthiness checks on delete results
rg "const \w+ = await client\.\w+\.delete" --type ts -A 3 | rg "if \("

3. Test against the live API. Spin up an integration test that does an actual delete in a Cloudflare staging account, asserts on the return shape. Pre-v6, the response is an object. Post-v6, it's null. If your test was just "did the call resolve without throwing," it passes both sides — and that's the gap.

4. Add a runtime shape check on critical Cloudflare calls. This is the durable fix. The contract you depend on isn't "this API call succeeds" — it's "this API call returns the structure we expect." Watching the response shape over time catches changes the SDK release notes might bury, future SDK majors might re-introduce, or the API itself might shift independent of the SDK.

That last point is what I've been building at FlareCanary. The Cloudflare v6 release isn't unique — it's the fourth or fifth major API surface I've watched make this kind of "loud-in-the-changelog, silent-at-runtime" shift in the last six weeks. Stripe's Dahlia release reshaped decimal_string fields from strings to typed Decimals. Microsoft stripped OldValue/NewValue from Dataverse audit events going to Purview. GitHub silently removed payload.commits from PushEvent. The pattern is the same: the changelog is honest, the SDK type changes if you read them, but the runtime shifts under code that compiled fine.

The honest defense is to monitor the response shapes you depend on. Either roll your own — cron a script that calls your top N Cloudflare endpoints, hashes the response shape, diffs against a baseline — or let something like FlareCanary do it for you.

The Bigger Pattern

Cloudflare's v6 changelog is good. The breaking changes are listed, the migration paths are documented, the deprecations are marked. Honestly better than most major API releases.

And it's still possible to be silently wrong after upgrading.

The reason is that runtime semantics aren't fully captured in type signatures. "This method now returns null" is a type change that strict-mode TypeScript can catch. "Empty bodies now parse to undefined" isn't — the return type is whatever it was before, the runtime value just shifted. "Retry-After is now respected up to any value" isn't a type change at all. None of these surfaces will fail an npm run build.

The v6 release is also a useful reminder of how much of the Cloudflare API surface is now in this SDK — 106 resource sections, 885 source files. It's effectively impossible to review every method's behavior change manually. You can read the changelog, you can run your test suite, and you can still be surprised in production.

That's the gap response-shape monitoring fills. Status-200 plus expected structure plus expected types is a stronger signal than "the call returned without throwing." And it travels with you across SDK majors.

If you upgraded to cloudflare-typescript v6 and got bitten by one of these — especially the truthiness flip on delete results — I'd love to hear about it. Replies below.

GitHub Silently Removed payload.commits From PushEvent — Here's What Broke and How to Catch the Next One

FlareCanary — Sun, 10 May 2026 04:04:21 +0000

On October 7, 2025, GitHub stripped a bunch of fields out of the Events API without changing a version number. The commits array on PushEvent. The author name and email. author_association on issue/PR/review/comment events. All gone.

No HTTP error. No deprecation warning at request time. No API version bump. The endpoint still returned 200 OK. The JSON was still valid. The shape was just different than it used to be.

If you had a CI hook, an abuse-detection pipeline, a dashboard, an internal tool — anything that read PushEvent.payload.commits — it started returning undefined overnight.

What Actually Changed

From GitHub's August 8 changelog:

On PushEvent:

payload.commits[] — removed
Commit SHAs, author names, author emails, commit messages — all gone

On IssuesEvent, PullRequestEvent, IssueCommentEvent, PullRequestReviewEvent, PullRequestReviewCommentEvent:

author_association — removed

GitHub ran a "brownout" test on September 8, 2025 — one day where the fields were pulled, then restored — and then made the removal permanent in October. The stated reason was abuse: scrapers were using the Events API to harvest commit metadata at scale. Fair enough. But from the consumer side, the surface looked like this:

Before (September):

{
  "type": "PushEvent",
  "payload": {
    "commits": [
      {
        "sha": "a1b2c3...",
        "author": { "name": "Jane", "email": "jane@example.com" },
        "message": "Fix tokenizer"
      }
    ]
  }
}

After (October):

{
  "type": "PushEvent",
  "payload": {}
}

Still 200 OK. Still valid JSON. Just silently missing the thing a lot of tooling was reading.

Why Nobody's Tests Caught It

This is the interesting part. Let's walk through why the usual safety nets didn't trip:

Unit tests didn't catch it because unit tests use fixtures, and fixtures are frozen in time. The test data had commits; production no longer did.

Integration tests didn't catch it unless they were running against the live GitHub API and asserting on the shape of the response. Most integration tests assert on behavior ("does our system process a push event?"), not structure.

TypeScript didn't catch it because TypeScript can't catch what it can't see. The field type is still defined in your Octokit types. The runtime object just doesn't have the field. Your code happily accesses payload.commits and gets undefined, then calls .map() on it and throws.

The API version didn't change because GitHub's Events API isn't versioned the way REST APIs with dated versions are. There was no pinned version to stay on. Consumers who wanted the old shape didn't have that option.

Error monitoring didn't flag it early because for a lot of code paths, the failure mode wasn't an exception — it was empty output. Your abuse detector processed the event, saw no commits, and marked the user clean. Your dashboard showed a zero. Your pipeline ran through the "empty case" branch.

Here's what showed up in GitHub Community Discussion #177111 after the change landed:

"This is a silent breaking change. Our abuse-detection pipeline has been running on empty events for a week and we only noticed because a nightly job alerted on throughput being anomalously low."

That's the worst version of a schema change. Not a crash. Not an alert. Just quietly wrong data flowing through your system.

The General Pattern

This isn't a GitHub problem. It's an API surface problem, and it happens constantly:

Stripe's 2025-03-31 "Basil" release removed billing_thresholds from subscriptions and killed the Upcoming Invoice API outright. Teams that had moved their account default version without re-pinning webhooks got silently migrated.
Plaid's May 2025 changes renamed zip to postal_code, state to region, and flipped some empty-string fields to null. Anything doing .trim() on those fields stopped working.
OpenAI's Responses API exposed per-turn shape variance — reasoning appears and disappears depending on whether a tool was called — which static typing can't model.

The common thread: the API provider has legitimate reasons to change the shape (abuse mitigation, data correctness, new capabilities). The consumer's tests assume a frozen structure. The gap between those two realities is where production breaks.

How to Actually Catch This

There are three honest defenses, in order of how much they actually help:

1. Pin what you can pin. Stripe, OpenAI, Shopify — these APIs offer explicit version headers. Use them. Don't move forward without a deliberate upgrade. This doesn't help for GitHub's Events API (no versioning) but it helps everywhere it's available.

2. Assert on structure in integration tests. Not just "did we process the event" but "does the payload have the field we rely on." This catches the problem in CI instead of prod — but only if your tests actually run against live endpoints regularly.

3. Monitor the response shape in production. This is the one most teams skip. Poll the endpoints you depend on (or sample live traffic), record the structure over time, and diff against a learned baseline. When a field disappears or changes type, you get an alert before your dashboards go empty.

The third defense is what I've been building at FlareCanary. Point it at your critical endpoints — the ones whose schema changes would make your Monday morning terrible — and it polls them on a schedule, learns the expected structure, and flags drift. Removed fields, type shifts, nullability changes, new fields that might signal a migration. Severity-classified so a new optional field is informational and a removed field is an alert.

You don't strictly need a tool for this. You can cron a script that calls your top 5 endpoints, hashes the field set, and diffs. The point is that some layer needs to be watching the shape, not just the status code.

The Harder Question

The thing the GitHub Events change really surfaces is this: how many of the APIs your service depends on actually have a team watching their response shape?

Most teams I've talked to know their dependency graph at the package level. They can tell you what version of Stripe's SDK they use, what OpenAI model they call, what GitHub endpoints they hit. Almost none of them can tell you whether the response from those endpoints has changed structure in the last month.

That's the monitoring gap. HTTP status codes tell you an endpoint is up. Response times tell you it's fast. Neither tells you the data contract is still what you thought.

If any of the Events API consumers mentioned in the community threads had been diffing /events responses against a baseline, they'd have caught the September 8 brownout and had a full month's warning before the permanent cut. The capability to catch it existed. The habit to watch for it didn't.

That's the real lesson, and it applies to every API you don't control.

If you've been hit by an API schema change that slipped through your tests, I'd genuinely like to hear about it — especially the "empty output, no error" variety. Replies below, or hit me up if you want to compare notes.

Microsoft Stripped OldValue/NewValue From Dataverse Audit Events Going to Purview on May 1 — Anomaly Rules Now See Nothing

FlareCanary — Sat, 09 May 2026 04:11:18 +0000

If you run anomaly detection or DLP correlation on Microsoft Purview audit events sourced from Dataverse, your rules went silent on May 1, 2026.

The events still arrive. The row counts in Purview are the same. The activity dashboards look identical. Every audit envelope continues to ship the metadata you'd expect — actor, timestamp, table, action type, record ID. The only thing missing is the part most security teams were actually using.

The before-and-after field values are gone.

This is Microsoft 365 Message Center post MC1239891: "Information regarding removal of field-level value changes in audit events sent to Microsoft Purview". Effective May 1, 2026. Field-level OldValue / NewValue payloads are stripped from Dataverse audit events as they cross into the Purview unified pipeline.

Microsoft frames it as a privacy improvement, and they're not wrong — Purview-side consumers (SIEM forwarders, third-party connectors, e-discovery tooling) were aggregating sensitive PII into a place where the access controls weren't necessarily as tight as the originating Dataverse environment. Stripping the field values at the boundary closes that.

The cost of that improvement, though, lands on every team whose detection logic was built on top of those values.

What's Still There vs. What's Gone

What still flows to Purview after May 1:

Audit row metadata — RecordType, Operation, UserId, ObjectId, CreationTime, Workload, OrganizationId
Table and record identity — entity name, record GUID, what was acted on
Action type — Update, Create, Delete, Access
Field name list — which attributes changed (in many cases)

What's gone:

OldValue — the value of each changed field before the update
NewValue — the value after
Any nested change-detail payload that previously contained those values for Dataverse audit events specifically

Existing audit rows from before May 1 retain their original payload. Only newly-created audit events created after the cutover have the stripped shape. That makes the regression invisible to retrospective queries — any test you run against a "known good" audit record from April still passes. The new audits don't.

Why This Looks Like Nothing Changed

The reason this is a textbook silent failure has three parts.

1. Row counts don't move. Audit volume in Purview is unchanged — every action that produced an event before still produces one. SIEMs that alert on "audit gap" or "logging stopped" don't trigger.

2. Dashboards still populate. Microsoft Sentinel, Splunk, Chronicle, and the rest get their hourly Purview pull. The records arrive. The widgets refresh. The "audit activity" panels show the same line. There's no failure indicator at the platform level.

3. The query language doesn't error. Detection rules in KQL, SPL, etc. that referenced OldValue or NewValue don't return errors when the field is missing — they return no rows. Empty result sets read as "no anomalies detected." Which is exactly the value those queries return when the world is fine. A query saying "alert when OldValue == 'Active' AND NewValue == 'Inactive' for AccountStatus" stops firing because the where-clause never matches anything. Nobody knows the rule went mute. They know is the alerts stopped, and "the alerts stopped" has a thousand benign-looking causes.

If your compliance program is built on these correlations — privileged-field changes, status flips, balance adjustments, role escalations, recipient-redirections — the rules went silent five days before this article was written, and it's likely nobody has noticed yet.

Concrete Detections That Just Stopped Working

A non-exhaustive list of rule patterns that depend on field-level deltas in Purview-sourced Dataverse events:

Status-flip detection. Account flipping from Active → Inactive outside business hours. Lead flipped from Disqualified → Qualified without an approval workflow. Sales-stage regression. All of these are "where OldValue == X AND NewValue == Y" rules.
Privileged-field watch. Role membership changes, privilege grants, security-group membership flips on Dataverse identity records. The list of what fields changed still reaches Purview; the values themselves don't.
Financial guardrails. Watching for credit-limit increases, discount-percentage bumps, payment-term extensions beyond a threshold. The delta — "increased from 30 to 90 days" — was the rule. The new event reports "PaymentTerm changed" with no values.
PII redirection alerts. A common pattern: alert when the email address on a contact record changes to a different domain than the prior value (used to catch impersonation / account-takeover). Both the prior and new domains were the rule. Both are gone.
Bulk-edit anomaly. "User edited 50 contact records in 5 minutes, where 80% of the changes set Status = 'Disqualified'" — required reading the resulting NewValue. Now the rule sees 50 changes; can't see what they were.
Record-merge correlation. Reconstructing what was kept and what was lost in a merge required the before/after on each field. Audit still shows the merge happened. The contents of the merge are no longer in Purview.
Compliance-comparison reporting. Quarterly reports that compute "X% of contact records had their consent-flag flipped from Granted → Revoked" — these rolled up OldValue/NewValue from Purview. Reports go to zero.

These are all rules that pre-date May 1, 2026 and were green on April 30. They'll stay green after May 1 because empty result sets don't generate alerts.

Why CI / Validation Didn't Catch It

The same shape of the problem we keep seeing on every silent breaking change.

Detection rules don't have unit tests. Most security-rule frameworks let you author KQL/SPL/Sigma but don't ship a way to assert "this rule produces N alerts when given this fixture." If you have such a test harness — congratulations, you're in the top 1% — but it's almost certainly using fixtures recorded before May 1, when OldValue still existed. The tests pass against the old shape; production sees the new shape.

Audit volume is the canary, and the canary is fine. Most teams monitor Purview ingestion volume. Volume didn't drop. The canary keeps singing.

Microsoft's communication channel. MC1239891 went into the Microsoft 365 Message Center. If your security architect doesn't read MC posts that look like they're for the Power Platform admin (because the dependency chain to Purview-side detection isn't visible from the post's title), the change lands without anyone hearing it. The post mentions Purview, but it's filed under Power Platform.

Organizational seam. Dataverse changes are owned by the Power Platform admin / D365 team. Purview detection rules are owned by the security team. The fact that a Power Platform configuration change blanks out a security team's detection logic crosses a domain boundary that no playbook usually covers.

The Real Migration Path

Microsoft's recommended workaround is correct, but it requires moving where your detections live.

Option A: Pull from Dataverse Web API directly. The before/after values are still stored in Dataverse — they didn't go anywhere. They are accessible via the RetrieveAuditDetails API on the audit table. The flow is:

Audit row (in Dataverse) → RetrieveAuditDetailsRequest →
  AttributeAuditDetail.OldValue / .NewValue

You build a connector that polls Dataverse audit on a schedule, pulls the audit-detail rows for changes you care about, and pushes the enriched events into your SIEM as a separate stream. This is more work than what existed before (Purview was doing the heavy lifting) and the data isn't in the same query store as the rest of your Purview data, so cross-table correlations get harder.

The audit-detail API has a few footguns worth knowing in advance:

Large field values are truncated at 5 KB and the response shows an ellipsis. Long-text fields (description, comments) can't be fully reconstructed.
The user calling the API needs prvReadAuditSummary. A service principal that worked for the Purview pull may not have this privilege on the Dataverse side.
Audit data isn't accessible via the TDS / SQL endpoint. You can't join it to other Dataverse tables through the SQL surface — has to be via the Web API or Organization Service.

Option B: Switch to Dataverse-native detection. Run the rules against the Dataverse audit table itself, via Power Automate flows or scheduled functions, and only forward the result (a fired alert) to your SIEM. This keeps the field values inside the Dataverse compliance boundary, which is also Microsoft's preference — it's the privacy-preserving path. Trade-off: you lose centralization. Each Dataverse environment becomes its own detection point.

Option C: Accept the loss. For a subset of rules where the fact that a field changed is enough, drop the value-comparison clause and alert on any change to the watched field. This widens the alert volume considerably. It's a fallback, not a replacement.

Whichever path you pick, the migration sequence that actually holds is:

Inventory. Grep your detection content (Sentinel rules, Sigma packs, Splunk content, custom KQL) for OldValue and NewValue. Anything that came out of Audit.General or Dataverse-sourced workloads is in scope.
Triage. Sort by criticality (privileged-field rules first), by event volume (low-volume rules first to reduce blast radius), and by whether the rule is "any change" (still works) vs. "specific value transition" (broken).
Replace. Build the Dataverse-side pull or rewrite as Dataverse-native rules. Validate end-to-end against a known test transition.
Run both paths in parallel for a sprint. Compare alert counts pre- and post-migration. Resolve gaps before tearing the old (now empty) rules out.
Update playbooks. SOC runbooks that say "pivot to OldValue/NewValue in the Audit row" need to be rewritten to "pivot to the Dataverse audit_audit_details link in the source environment."

How To See The Next One

This pattern — the data still flows, the shape just changed — is not unique to Microsoft. It's the most common breaking-change pattern this year, by a good margin. Stripe's Dahlia release reshaped decimal fields in the SDK. GitHub silently retired seven org-security fields. Power Platform stripped two attributes from a deeply nested payload. The HTTP envelope didn't move. The endpoint didn't 404. The thing inside changed.

The defense is to watch the shape of every external response your detections, integrations, and consumers depend on. Not the volume, not the latency, not the status code — the shape. The presence and type of every field, on every payload you read.

That's the gap FlareCanary plugs. Point it at the endpoints and event streams you depend on, and it learns the response structure, then alerts on field disappearances, type changes, and shape drifts. For a Purview/Dataverse setup this would have caught OldValue / NewValue going to null (or being absent entirely) on the first event after May 1, before the silence reached the alerts.

You don't strictly need a tool. You need a habit. Watch the runtime shape of every external response you depend on. Detection rules built on top of fields are only as durable as the fields. The ones in MC1239891 vanished cleanly, with no error, on a quiet Friday in May. The next ones will too.

If your security tooling depends on Dataverse audit field values — or you've been bit by any silent shape-strip on a payload — drop a note. The "audit volume looks fine, the rules just stopped firing" failures are the exact kind we're tracking.

Stripe's 2026-04-22 Dahlia Release Quietly Changed unit_amount_decimal From String to Decimal — Your `==` Checks Are Now Always False

FlareCanary — Sat, 09 May 2026 04:05:05 +0000

On April 22, 2026, Stripe shipped the Dahlia API version. Among the changes was one that doesn't sound like much in the changelog and absolutely is in production: every field formatted as decimal_string — unit_amount_decimal, quantity_decimal, fx_rate, and friends — changed type in the SDKs.

In stripe-python, those fields used to be str. They are now decimal.Decimal.

In stripe-node, they used to be string. They are now Stripe.Decimal — a class Stripe ships inside the SDK package.

Same for stripe-dotnet, stripe-go, stripe-java, stripe-php, stripe-ruby. Every official SDK got the same reshape.

The wire format did not change. Stripe's HTTP responses still serialize these fields as JSON strings. The SDKs now parse them into a typed Decimal on the way in, and serialize them back to strings on the way out. From the docs:

The SDK handles conversion to and from the string wire format transparently.

That sentence does a lot of heavy lifting. It is true on the request and response side. It is not true in any code path between those two boundaries.

What This Quietly Breaks

If your code does any of the following with a decimal_string field, it broke when you bumped the SDK to a Dahlia-compatible version. None of these will throw at SDK install time, none will fail unit tests that mock Stripe with the old shape, and none will produce a clean stack trace pointing back at the change.

Equality checks against strings

# Before
if line_item.unit_amount_decimal == "1500":
    apply_discount()

# After: line_item.unit_amount_decimal is Decimal('1500'), never == "1500"

Decimal("1500") == "1500" is False. Always. No coercion, no warning. The if branch stops firing. Whatever logic depended on it goes silently dead.

String operations

// Node — was: "1500.00".startsWith("1") → true
// After: price.unitAmountDecimal is Stripe.Decimal — no .startsWith()
if (price.unitAmountDecimal.startsWith("1")) { /* ... */ }
// TypeError: price.unitAmountDecimal.startsWith is not a function

# Python — was: "1500.00"[:2] → "15"
# After: Decimal('1500.00')[:2] → TypeError: 'decimal.Decimal' object is not subscriptable
prefix = line_item.unit_amount_decimal[:2]

Less-obvious variants: len(), .split('.'), regex matching. Anything that treated the field as a string.

JSON serialization

import json
json.dumps(stripe_response)
# TypeError: Object of type Decimal is not JSON serializable

This is the one that bites the hardest in practice. Backends that json.dumps() a Stripe object — to log it, to enqueue it on a job queue, to forward it to an analytics pipeline — start raising at the serialization boundary, not at the API call. The traceback points at the dumps line, not at Stripe.

In Node, JSON.stringify(price) doesn't throw, but it serializes the Decimal class via its toJSON (if defined) or its default object representation. Either way the output shape changes from "1500" to either "1500" (if toJSON returns a string), or {} / something object-shaped (if not). Downstream consumers that parse and re-validate may reject it.

Mixed-type arithmetic

# Python: was string, you'd cast first
total = sum(float(li.unit_amount_decimal) * li.quantity for li in items)
# Now li.unit_amount_decimal is Decimal, li.quantity is int — mixing Decimal*int is fine
# But: total + 0.01 (a float) → TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'float'

Decimal + float raises in Python. So the moment your accumulator picks up a float anywhere in the chain — a hardcoded 0.01 for rounding, a return value from another library — addition explodes. The location of the explosion can be far from the SDK boundary.

Database driver type expectations

Most drivers handle Decimal cleanly (psycopg2, asyncpg, the .NET SQL drivers, JDBC). Some don't, especially older or thin drivers, NoSQL clients, and ORMs that do their own coercion. If you've been passing unit_amount_decimal straight into a query parameter, you may now hit a different code path in the driver — one that's slower, or that converts to a different SQL type, or that silently truncates.

Logging and observability tools

Loggers that string-coerce values write "Decimal('1500.00')" to the log line, not "1500.00". Search queries against your log index for the price value miss. Sentry breadcrumbs change shape. Datadog APM spans tagged with the price string lose dashboarding continuity. Nothing breaks loudly; the searches just stop matching.

The Wire-Format Trap

Here is the silent-fail vector that has the highest blast radius.

Stripe webhooks deliver raw JSON. If your handler parses the request body itself and accesses fields directly — body["data"]["object"]["unit_amount_decimal"] — those fields are still strings. They came off the wire as strings, and you never went through the SDK's deserialization path.

Stripe SDK retrievals — stripe.Price.retrieve(...) or stripe.checkout.Session.retrieve(...) — return Decimal-typed fields. Same field name, same logical value, different runtime type.

So: in one part of your codebase, unit_amount_decimal is a string. In another, it's a Decimal. Both came from "Stripe." Both are correct. Whether the equality check, the comparison, the arithmetic, or the serialization works depends on which codepath produced the value.

The classic version of the bug is: webhook handler stores the raw payload's unit_amount_decimal in a database column, scheduled job retrieves the price via SDK and compares it to the stored value, comparison is always False, the job concludes the price changed, fires a re-pricing flow, customer gets re-charged.

The fix is not "always go through the SDK" or "always parse the raw body" — both have legitimate use cases. The fix is to normalize at the edge: if you're touching this field, decide whether it lives as a string or a Decimal in your domain model, convert immediately, and never let the unconverted form leak past the boundary.

Why The Migration Slipped

Same answers as every other silent type change.

The SDK's own changelog is short on it. The line in the release notes is "all decimal_string fields changed type from string to Decimal." Reading that fast, you assume it's a developer-experience win — typed values, better arithmetic. The downstream consequences for code that already treated those fields as strings aren't called out.

Types didn't catch it where you'd expect. In TypeScript/stripe-node, the type does change — string → Stripe.Decimal. If your code depends on string operations and you ran tsc, you'd see errors. But: a lot of code uses any at the boundary, especially in legacy projects. A lot of code marshals through JSON and back and loses the type entirely. And a lot of code is JavaScript. None of those cases get a compile error.

In Python, there are no compile-time types unless you've fully type-annotated your Stripe-touching code, which most teams haven't.

In Go, the SDK uses concrete struct types and the change is visible in the type signature — Go users get the cleanest signal of any language.

Tests against fixtures. If you have unit tests that mock Stripe responses with hand-rolled JSON — strings on unit_amount_decimal — those tests pass against your old SDK code (parses to string) and your new SDK code (parses string to Decimal, both still match the assertion if you also coerced), or they don't. Either way, they don't reflect what production does, because production actually goes through SDK deserialization.

Account-level API version pinning. Stripe lets you pin your account's default API version. If you pinned, the wire format won't move on you. But the SDK reshape happens regardless of the account default — it's a client-side behavior. Bumping stripe-python from 11.x to 12.x with the same account API version still flips your local types.

Dependabot. A Dependabot PR bumps your stripe dependency, your fixture-based tests pass, you merge, deploy, and ship the type flip into production. Same Dependabot story we wrote about for the Basil migration — different field reshape, same vector.

A Migration That Actually Holds

Pin the SDK in package.json / requirements.txt / equivalent. Don't let the major version float. The Dahlia-aware SDK majors are Python 12.x, Node 22.x, .NET 49.x — pin explicitly.
Grep the codebase for the affected field names: unit_amount_decimal, quantity_decimal, fx_rate, plus any custom field on a Stripe object that ends in _decimal. Note every reference. (grep -r "unit_amount_decimal" . is fine to start.)
Classify each reference: is it string-style (equality, slicing, length, JSON serialize) or numeric-style (arithmetic, comparison, sorting)? String-style is what breaks; numeric-style is what gets better.
Convert at the edge. Wherever a Stripe object enters your domain (after SDK call, after webhook parse), coerce all _decimal fields to a single canonical type — either str if your domain is string-typed, or Decimal if it's numeric-typed. Don't mix.
Update test fixtures. If you mock Stripe with hand-rolled JSON, your fixtures need to round-trip through stripe.util.convert_to_stripe_object (Python) or the equivalent SDK helper, so your tests see the post-deserialization shape, not the wire shape.
Audit JSON serialization paths. Any place you json.dumps() a Stripe object needs a Decimal-aware encoder (json.dumps(obj, default=str) is the quick fix; a custom JSONEncoder is the right fix).
Stage behind a flag. Roll the SDK bump out incrementally — one service at a time, ideally one with low write volume first. Compare logs and outputs against the prior version for a few days before promoting.

How To See The Next One Coming

The reshape pattern — "we kept the field name, we kept the API version contract, we just changed the runtime type the SDK hands you" — is going to keep happening. Stripe is not the only vendor doing it. Every SDK that ships a vendored numeric type, datetime type, or money type can do this in a minor SDK release without bumping the API version, and it's almost always a real improvement.

The defense isn't "block SDK upgrades" — that runs out of road on security patches. The defense is to know which fields you depend on, what shape they have today, and to find out the moment that shape changes — before the deploy.

That's the gap FlareCanary plugs. Point it at the endpoints you depend on (Stripe price retrieve, subscription retrieve, customer retrieve) and it polls them, learns the response structure, and alerts when a field's type or shape moves — including SDK-side reshapes if you point it at SDK-deserialized output, and wire-format changes if you point it at raw HTTP. Removed fields and type flips are alerts; new optional fields are informational.

You don't strictly need a tool. You need a habit. Watch the runtime shape of every external response you depend on. The Dahlia decimal reshape is a textbook case of an upgrade that the type system in some languages catches, the type system in others doesn't, and the test suite in almost all of them misses entirely — because the test suite is checking the JSON shape, and the JSON shape didn't move.

The runtime shape did. That's the only thing that actually matters.

If you've been bit by the Dahlia type reshape — or by any silent SDK type flip on another API — drop a note. The "the wire didn't change but the SDK did" failures are the exact ones we hear about most.

GitHub's code_scanning_upload Rate Limit Field Goes Away May 19 — Your SARIF Pre-Flight Check Is About to KeyError

FlareCanary — Fri, 08 May 2026 04:04:05 +0000

If your CI pipeline or security tooling makes a pre-flight call to GET /rate_limit before uploading a SARIF file to GitHub, May 19, 2026 is your deadline. GitHub is removing the code_scanning_upload object from the response. Eleven days of runway from this article.

The headline change is small: one key disappears from a JSON response. The interesting part is what was actually inside that key — and the silent decision your gating logic has been making since you wrote it.

The exact shape change

Today, GET /rate_limit returns this under resources (truncated to the relevant keys):

{
  "resources": {
    "core":                 { "limit": 5000, "used": 1, "remaining": 4999, "reset": 1372700873 },
    "code_scanning_upload": { "limit": 5000, "used": 1, "remaining": 4999, "reset": 1372700873 }
  }
}

Starting May 19, 2026:

{
  "resources": {
    "core":                 { "limit": 5000, "used": 1, "remaining": 4999, "reset": 1372700873 }
  }
}

That's the whole change. The code_scanning_upload key is gone. There is no replacement key, because — as we'll get to in a second — there was never a separate quota to replace.

The four places this breaks

The pattern is the same KeyError/undefined/null pointer shape we covered with GitHub's merge_commit_sha removal last month. Different surface, same failure class.

1. Pre-flight gates on SARIF uploads.

The most common pattern in code-scanning automation:

import requests

resp = requests.get("https://api.github.com/rate_limit", headers=headers).json()
csu = resp["resources"]["code_scanning_upload"]
if csu["remaining"] < 10:
    print(f"Low budget — sleeping until {csu['reset']}")
    time.sleep(csu["reset"] - time.time())

# upload the SARIF
upload_sarif(...)

After May 19, the second line raises KeyError: 'code_scanning_upload'. The job exits non-zero, the SARIF never uploads, the security dashboard goes stale, nobody notices because the alert was wired to the upload-success webhook, not the rate-limit-check failure.

2. PyGithub and Octokit field accessors.

If your code uses PyGithub's RateLimit object, the attribute access is rate_limit.code_scanning_upload. After May 19, that attribute will resolve to None (PyGithub builds the object lazily from the JSON response — missing keys become None rather than AttributeError), and rate_limit.code_scanning_upload.remaining will then raise AttributeError: 'NoneType' object has no attribute 'remaining'.

Octokit's TypeScript types currently mark the field as required. A typed octokit.rest.rateLimit.get() consumer that destructures the field will fail at compile time the next time you bump @octokit/openapi-types past the cutoff. That's actually the good failure mode — the type checker catches it before deploy.

3. Dashboards graphing the field separately.

If you graph code_scanning_upload.remaining over time on a Grafana panel, the metric flatlines on May 19 and your alert thresholds (e.g., "page if rate-limit headroom < 100") fire constantly until someone notices the panel is querying a key that no longer exists. Whether this is loud or silent depends on how your collector handles missing keys — Telegraf's HTTP-JSON input plugin emits a 0 for missing fields by default, which is the worst possible outcome (silent under-reporting).

4. Schema-validating clients.

Any client that validates against an OpenAPI schema and treats code_scanning_upload as required will reject the new response as malformed until the schema is bumped. This is the most niche failure but the loudest — and it's how people who run openapi-typescript against GitHub's spec catch this kind of change automatically. Most teams don't.

The deeper twist: the field was always shadowing `core`

This is the part that makes the change interesting rather than just annoying. From the GitHub Community discussion thread that prompted the deprecation:

"Rate Limit endpoint shows core and code_scanning_upload consuming the same quota during job"

It does, because they are the same quota. The code_scanning_upload object never held its own bucket. SARIF uploads consume from the standard core rate limit (5,000/hr authenticated, 15,000/hr for GitHub Apps). The duplicate object in the response was a documentation-of-intent artifact — GitHub once planned to give SARIF its own bucket, never did, and the field has been a confusing copy of core ever since.

Which means any of these patterns has been wrong for years:

# Pattern A — gating on the wrong field
if rate_limit.code_scanning_upload.remaining > 10:
    upload_sarif()
# This was always equivalent to checking core. The if/then was redundant.

# Pattern B — assuming separate budgets
core_budget = rate_limit.core.remaining
sarif_budget = rate_limit.code_scanning_upload.remaining
total_budget = core_budget + sarif_budget   # double-counted; the budget is one bucket

Pattern B is the silent-fail mode. Code that double-counts the budget thinks it has 10,000 requests of headroom when it actually has 5,000. On a busy day with concurrent CI shards, the second half of the budget evaporates faster than the calculation expects, and the job hits HTTP 403 with X-RateLimit-Remaining: 0 partway through the run — without the rate-limit pre-check ever flagging it, because the pre-check was reading the (duplicate) code_scanning_upload value while the upload calls debited from core.

The May 19 removal is GitHub making this implicit truth explicit. The code that breaks loudly (KeyError) was less wrong than the code that was silently summing the same quota twice.

The migration

For the loud-fail case (KeyError, AttributeError):

# Before
csu = resp["resources"]["code_scanning_upload"]
if csu["remaining"] < 10:
    sleep_until_reset(csu["reset"])

# After
core = resp["resources"]["core"]
if core["remaining"] < 10:
    sleep_until_reset(core["reset"])

For PyGithub:

# Before
rate = gh.get_rate_limit()
if rate.code_scanning_upload.remaining < 10:
    ...

# After
rate = gh.get_rate_limit()
if rate.core.remaining < 10:
    ...

For Octokit users on TypeScript: bump @octokit/openapi-types past the cutoff, run tsc, and let the type errors guide the rename.

For dashboards: drop the code_scanning_upload panel. The core panel was always showing the same numbers; you don't need both.

The harder check: is your code-scanning quota actually safe?

Here's the question the migration itself doesn't answer: now that code_scanning_upload and core are the same explicit bucket, does your CI fleet actually fit inside core once you stop double-counting?

For a single repo doing a few SARIF uploads per push, yes. For a security team running GitHub Advanced Security across hundreds of repos with parallel CodeQL workflows on every PR, the answer might be no. The 5,000/hr limit per token is shared across:

All core-bucket calls (most of the REST API)
All SARIF uploads (was already true; now visibly so)
All Dependabot manifest fetches you do via the API
Any other automation hitting the same auth

Run the numbers before May 19. If your aggregate core consumption was sitting comfortably below 5,000 because you assumed code_scanning_upload was a separate budget, you may be about to discover otherwise — except the discovery happens via 403s on uploads, not via your rate-limit pre-check.

The clean fix for high-volume code scanning is using a GitHub App with installation tokens (15,000/hr, 12,500/hr per installation, plus the API-only core headroom). That's a token-architecture change, not a one-line field rename.

The pattern across these GitHub deprecations

This is the third quiet-field removal we've covered in five weeks:

April 27 — merge_commit_sha removed from PR responses in the 2026-03-10 API version
April 28 — Seven org security fields retired (PATCH returned 200 but applied nothing)
May 19 — code_scanning_upload removed from /rate_limit

Each one is a one-line schema change that becomes a multi-hour incident in production because the failure surfaces aren't obviously connected to the announcement. They're not the headline breaking changes from the API version page — they're the small reshapes that nobody on the team is monitoring.

The unifying habit: pin the response shape of every GitHub endpoint your automation depends on, diff it on a schedule, and alert when a key disappears. That's what FlareCanary does — it polls the endpoints you point at, learns the response shape, and flags removed fields with severity classification so the SARIF-upload script's pre-flight check finds out about the change in your alerting channel rather than at 2 AM during a security release.

Action items, in order, before May 19

Today: grep your codebases for code_scanning_upload. Anywhere it appears in JSON parsing, dashboard config, or schema validation is a migration target.
This week: rename to core in pre-flight checks and verify the gate still does what you want — most "the SARIF budget is fine" gates were already lies.
This week: verify core-bucket headroom across your aggregate token usage. If you've been flying close to the limit while assuming you had two buckets, plan token splits or move to GitHub App auth.
Before May 19: bump @octokit/openapi-types and PyGithub past the cutoff in CI to surface compile/runtime errors before the production endpoint changes shape.
After May 19: keep the rename. GitHub has been quietly trimming dead fields all spring. The next one will follow the same pattern.

A 200 response on /rate_limit tells you the request was accepted. It doesn't tell you the field you're reaching for is still there.

If your code-scanning automation has been gating on code_scanning_upload and you found something interesting when you ran the numbers — drop a reply with the shape of the surprise. The shadow-quota pattern is broader than just this field.

DEV Community: FlareCanary

Your Shopify discount is in the admin but missing from the API — the 2026-07 market-eligibility trap

1. A clean 200 with the discount missing

2. Fetching by ID returns null — which reads as "deleted"

3. Sync, audit, and reconciliation jobs undercount with no signal

4. Bulk operations and anything sharing the query layer inherit the gap

5. After you upgrade, the inheritance rules are their own trap

The fix

Claude Opus 4 and Sonnet 4 retire June 15 — your `claude-opus-4-0` alias is about to start failing

1. The claude-opus-4-0 and claude-sonnet-4-0 aliases retire with the snapshot

2. Don't confuse 4-0 with 4-1

3. Bedrock and Vertex AI run their own schedule

4. Mocked SDK tests will not catch this

5. Model-router fallback configs go silent

6. Evals and comparison harnesses lose their baseline

The fix

A clean migration checklist

xAI retired 8 Grok models on May 15 — the slugs still resolve, so your bill and output quality changed silently

1. grok-code-fast-1 now bills at grok-4.3 rates — and that's your highest-volume slug

2. The reasoning slugs are now answering at low effort

3. Cost-attribution dashboards now lie

4. grok-imagine-image-pro is a different image model now

5. Fallback chains lost their cheap degraded mode

6. Pinned eval baselines now track a moving target

What to actually do

Gemini's Interactions API default flips May 26 — your interaction.outputs reads will go undefined and tool calls silently stop

The Timeline

What Actually Changes

1. outputs[] → steps[] (the read path you almost certainly have)

2. response_mime_type → polymorphic response_format

3. image_config moves out of generation_config

4. Streaming SSE event names rename

5. Function calls live in steps, not outputs

6. The thought step shape changes too

The Silent Surfaces

How To Detect It Before May 26

Why This Is Worth Paying Attention To

Notion's API Now Caps Pagination at 10,000 Results — Your 'Fetch All Rows' Sync Is Silently Truncating

What Actually Changed

Why This Is a Silent Failure, Not a Loud One

Who's Exposed

How To Detect It

The Pattern

Supabase's Management API OAuth Endpoint Switches From 201 to 200 on May 26 — Here's What Silently Breaks

What Actually Changes

The Four Quiet Surfaces

Who Should Audit Right Now

The Migration Is Trivial; The Audit Is the Work

The Pattern, Beyond Supabase

AEM Cloud Stops Receiving Adobe Updates June 11 If You Use Deprecated APIs — Here's the List and How to Tell

The Escalation, In Adobe's Own Words

The Four Quiet Surfaces

The Actual Deprecated API List

How to Actually Find Your Usage

What Happens at the Pipeline Level When You Don't Migrate

Migration: What's Actually Drop-In and What's Not

What to Google If You're Already Past the Cliff

The Pattern, Beyond AEM

Cloudflare TypeScript SDK v6 Made 133 Methods Return null and Empty Bodies Return undefined — Here's What Broke

What Actually Changed

The Silent-Fail Surfaces

Why TypeScript Doesn't Save You

How to Find If You're Affected

The Bigger Pattern

GitHub Silently Removed payload.commits From PushEvent — Here's What Broke and How to Catch the Next One

What Actually Changed

Why Nobody's Tests Caught It

The General Pattern

How to Actually Catch This

The Harder Question

Microsoft Stripped OldValue/NewValue From Dataverse Audit Events Going to Purview on May 1 — Anomaly Rules Now See Nothing

What's Still There vs. What's Gone

Why This Looks Like Nothing Changed

Concrete Detections That Just Stopped Working

Why CI / Validation Didn't Catch It

The Real Migration Path

How To See The Next One

Stripe's 2026-04-22 Dahlia Release Quietly Changed unit_amount_decimal From String to Decimal — Your `==` Checks Are Now Always False

What This Quietly Breaks

Equality checks against strings

2. Fetching by ID returns `null` — which reads as "deleted"

1. The `claude-opus-4-0` and `claude-sonnet-4-0` aliases retire with the snapshot

2. Don't confuse `4-0` with `4-1`

1. `grok-code-fast-1` now bills at grok-4.3 rates — and that's your highest-volume slug

2. The reasoning slugs are now answering at `low` effort

4. `grok-imagine-image-pro` is a different image model now

1. `outputs[]` → `steps[]` (the read path you almost certainly have)

2. `response_mime_type` → polymorphic `response_format`

3. `image_config` moves out of `generation_config`

5. Function calls live in `steps`, not `outputs`

6. The `thought` step shape changes too

The deeper twist: the field was always shadowing `core`