Forem: FlareCanary

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.

Twilio's Transit CallerID Sunset on May 31 — Your Voice Flows Already Look Broken in Six Countries and You Probably Don't Know

FlareCanary — Fri, 08 May 2026 04:01:48 +0000

If your product makes outbound voice calls through Twilio and you're presenting a CallerID that isn't a Twilio-owned or Verified CallerID number, May 31, 2026 is a date you need on the calendar. Twilio is sunsetting Transit CallerID. Six countries are already blocking these calls today.

The reason this one is dangerous isn't the cutoff itself — Twilio has been clear about the date for months. It's the failure mode before the cutoff, in the regions that have already started enforcing. The Twilio side of the call returns 200, the CallStatus webhook reports completed or in-progress, your aggregate latency dashboards stay green — and the call never reaches the called party because the regulated carrier drops it on the spec edge.

What Transit CallerID is, and what's changing

Twilio Voice lets you set a CallerID on outbound calls in three ways:

A Twilio-owned number on your account.
A Verified CallerID — a non-Twilio number you've proven you control via the verification call flow (OutgoingCallerIds resource).
Transit CallerID — pass any arbitrary number through the From parameter (Programmable Voice) or the SIP From header (Elastic SIP Trunking), and Twilio carries it as-is to the destination carrier without proving you control it.

Option 3 is what's going away. Starting May 31, 2026, Twilio will reject outbound calls whose CallerID isn't a Twilio-owned number, a Verified CallerID, or a CallerID delivered through Immutable Call Forwarding (more on that below).

The regulatory pressure isn't from Twilio. It's from national regulators tightening on caller ID spoofing. The countries already blocking unverified Transit CallerID at the carrier layer:

Australia
Brazil
Germany
Norway
Spain
Sweden

If your traffic terminates in any of those countries today, the calls are already failing. The question is whether your monitoring is telling you.

The silent-fail mode that gets under everyone's monitoring

This is the part that bit teams in March and April when the early enforcement started, and it's the part that's going to bite the long tail when May 31 hits the rest of the regulated markets.

Here's the call flow when a Transit CallerID call hits a country that's already enforcing:

Your code POSTs to /2010-04-01/Accounts/{AccountSid}/Calls.json with From=+15551234567 (your customer's CallerID, not yours), To=+49xxxxxxxxx, and a TwiML URL.
Twilio's API returns HTTP 201 with a CallSid.
Your statusCallback webhook fires initiated, then ringing.
The call traverses Twilio's network, hits the German carrier's edge (in this example), and the carrier drops it because the CallerID doesn't pass STIR/SHAKEN attestation or the local equivalent. Some regulators just block; others return a 503 Service Unavailable or a Q.850 cause code (16 — Normal call clearing) that looks identical to a normal hangup.
Your statusCallback fires completed with Duration=0 and CallStatus=completed.

The string completed is doing a lot of work there. In Twilio's status taxonomy, completed means "the call was set up and torn down without an explicit failure on the signaling layer." It does not mean "the called party picked up." It does not mean "audio flowed in either direction." A call that was administratively dropped by a regulated carrier with a clean 503 looks identical to a call that connected, played a 30-second message, and hung up — except for Duration and the absence of any RTP statistics.

If your app tracks CallStatus == 'completed' as success — and most do — your dashboard is lying to you. Every call to AU/BR/DE/ES/NO/SE has been silently failing for some teams since March.

Where to look for the truth

Three signals expose the silent fail. None of them are on the default Twilio monitoring page.

1. The Insights API call summary.

GET https://insights.twilio.com/v1/Voice/{CallSid}/Summary

Specifically the call_state and attributes.disposition fields. A regulator-blocked call surfaces as call_state=completed, disposition=no-answer or failed-attestation. The disposition lives in Insights, not in the Calls resource.

2. Per-event breakdown.

GET https://insights.twilio.com/v1/Voice/{CallSid}/Events

Look for an event with name=last_sip_response_code greater than 400, or name=carrier_attestation with a value of C or null. STIR/SHAKEN attestation C (gateway attestation) is what unverified Transit CallerID resolves to, and the regulated carriers in the six countries above reject it.

3. The hangup cause code on the completed callback.

Even on the basic statusCallback, Twilio includes the Q.850 cause when it's available: HangupCauseCode and HangupSource. A normal completion shows HangupSource=caller or callee. A regulator block frequently shows HangupSource=carrier with a code in the 21–27 range (call rejected, network out of order, requested facility not subscribed). Most apps don't read those two fields.

If you do nothing else before May 31, log HangupSource and HangupCauseCode on every status callback and graph the per-country rate of HangupSource=carrier. That single dashboard surfaces the silent fail today, before the global cutoff lands.

The migration paths

There are three migration targets, and they map to different use cases. Picking the wrong one means writing code that compiles but doesn't satisfy the regulator.

1. Static CallerID — use Verified CallerID

If your app always presents the same CallerID on every outbound call (e.g., your business's main line), the answer is to add it as a Verified CallerID on your account.

curl -X POST https://api.twilio.com/2010-04-01/Accounts/$ACCOUNT_SID/OutgoingCallerIds.json \
  --data-urlencode "PhoneNumber=+15551234567" \
  --data-urlencode "FriendlyName=Main Business Line" \
  -u $ACCOUNT_SID:$AUTH_TOKEN

Twilio places a verification call to the number. Whoever answers reads back a 6-digit code, and the number is then registered as a Verified CallerID. Once verified, calls using that number as From are treated as authenticated through May 31 and beyond. Verification needs to be re-run if the underlying number changes carrier or ownership — there isn't a long-term challenge mechanism, just a one-time call.

Static use case is the simplest migration. Most static-use teams will be fine if they verify their numbers before the deadline.

2. Dynamic CallerID where you control all the lines — port them to Twilio

If your app rotates between a small pool of CallerIDs (regional presence numbers, vanity lines), the cleanest path is porting those numbers into your Twilio account. Twilio-owned numbers don't need verification — they're the gold-standard CallerID and carry full STIR/SHAKEN attestation A.

This is the highest-effort migration if you have many numbers, because porting is a per-number process with carrier paperwork. Start the port at least 30 days before May 31 if you want to use this path.

3. Per-call dynamic CallerID where you don't own the numbers — Immutable Call Forwarding

This is the one that breaks the most assumptions. If your app's whole business model is "customer A calls in, we forward to customer B's mobile, and customer B sees customer A's CallerID" — call masking, virtual receptionists, two-sided marketplace voice, customer-support outdial showing your customer's branded number — none of the above two options works. You don't own customer A's number, and you can't verify a different number per call.

Twilio's answer is Immutable Call Forwarding, marketed as PV Immutable Call Forwarding (PV-ICF) for Programmable Voice and ESIPT Immutable Call Forwarding for Elastic SIP Trunking.

The mechanism is fundamentally different from Transit CallerID. Instead of a fresh outbound call where you assert a CallerID, the call leg is forwarded through Twilio as a B2BUA (back-to-back user agent) bridge — the inbound leg is a real call from customer A, and the outbound leg preserves customer A's identity through the bridge under STIR/SHAKEN's call diversion mechanism.

For Programmable Voice TwiML, this is a <Dial> invocation against a leg you've received, not a fresh outbound <Dial>:

<Response>
  <Dial callerId="{{the inbound caller's number, immutably forwarded}}">
    <Number>+49xxxxxxxxx</Number>
  </Dial>
</Response>

The constraint: the call must originate from an inbound leg you received. You can't synthesize an outbound call with PV-ICF — you need a real inbound to forward. For most call-masking products this is exactly what's happening today; the change is in how Twilio attests it on the way out.

For Elastic SIP Trunking the equivalent is configured at the trunk level under Call Transfer settings, with the "Caller ID for Transfer Target" knob set to Transferor (preserving the original caller's identity) instead of the default Transferee. SIP REFER carries the diversion header that the destination carrier honors as a forwarded leg, not a Transit CallerID.

If your product is in the marketplace/masking/virtual-receptionist category and you don't have ICF wired up before May 31, the migration is not a small change — you need to refactor your call paths so every dynamic CallerID call originates from an inbound leg, and your TwiML needs to flip from outbound <Dial> to inbound-then-<Dial>.

Why your tests probably don't catch it

This one shares the shape of the prior Twilio regional-domains intercept, but the silent-fail surface is wider. Five reasons it slips through:

Sandboxes don't enforce. Twilio's test credentials don't run STIR/SHAKEN attestation. Calls placed in test mode complete cleanly regardless of CallerID provenance. The validation only kicks in when the call hits a real PSTN destination.

Unit tests don't dial. They mock the SDK, assert that client.calls.create was called with the right From, and move on. The string +15551234567 is just as valid in a mock as a verified number.

Integration tests don't terminate internationally. Most teams' integration tests dial the team's own numbers — almost always US/CA. The six countries already enforcing are not on the default test list. Integration tests pass; production calls to AU/BR/DE/ES/NO/SE quietly drop.

CallStatus is a misleading signal. As covered above, completed doesn't mean delivered. Apps that key on CallStatus for success monitoring are systematically reporting blocked calls as successes.

The Twilio Console call log shows them as completed too. This one trips up support teams. The default call log view shows duration and status; a regulator-blocked call has duration 0 and status completed. It looks identical to a hung-up-on-ringback call, which happens for legitimate reasons all the time. Until you click into the call detail page and read the Insights events, there's no flag.

What to do, in order, before May 31

Today: log HangupSource and HangupCauseCode on every status callback. Graph the rate of HangupSource=carrier per destination country code. If the AU/BR/DE/ES/NO/SE rate jumps relative to baseline, you have Transit CallerID exposure live.
This week: audit your From numbers. Pull the last 30 days of Calls and group by the From field. Anything that isn't a Twilio-owned number (incoming_phone_numbers resource) or a verified OutgoingCallerIds entry is exposed.
Next week: classify by use case. Static lines → Verified CallerID. Owned but external → port to Twilio. Customer-presented per-call → ICF refactor.
Before mid-May: complete the Verified CallerID flow for static numbers. The verification call requires someone to answer and read a code, so this is a coordination problem, not a technical one. Don't leave it for the last week.
Before May 31: migrate the ICF path. This is the largest change for marketplace and call-masking products. Don't skip it because the cutoff date moves through your release schedule.
After May 31: keep the per-country HangupSource=carrier dashboard. The list of regulated countries will grow. Saudi Arabia, France, and Japan are all on the watch list of the same regulator coalition that drove the AU/BR/DE/ES/NO/SE rollouts. Today's six are not the last six.

How drift monitoring catches this class of change

The pattern in this Twilio change is identical to the one in the regional-domains deprecation we covered last month: a long pre-announced cutoff, an authoritative changelog post, and a per-region silent enforcement window before the global flag day. It also matches the GitHub merge_commit_sha removal, the OpenAI Responses input_text deprecation, and the Stripe Basil current_period_end move — all changes where the API surface kept returning 200 long after the underlying contract had drifted out from under the caller.

The fix at the architecture level is to stop treating "200 OK" as a success signal at the boundary. The API tells you the request was accepted; it doesn't tell you the contract still holds.

That's the gap FlareCanary was built to close. Point it at the Twilio Calls and Insights endpoints you depend on, and it polls on a schedule, learns the expected response shape, and flags when a field's nullability changes, when a new attestation field appears, when an enum tightens. Severity-classified so noise stays low.

You don't need a dedicated tool. You can cron a script that hits the relevant endpoints, hashes the field set, and diffs. The point is that some layer needs to be watching response shape and per-country dispositions, because the regulator-driven changes don't bump API versions when they tighten — they just tighten.

The harder pattern

This is the third Twilio incident we've covered in the series. Regional domains in April. A2P 10DLC required fields in June. Transit CallerID in May. Three different teams inside Twilio, three different changelog posts, three different failure surfaces — and the same silent-success pattern across all of them.

Most teams have a list of which Twilio products they use. Almost none of them have a list of which Twilio contracts they assume — which fields exist, which CallerIDs work in which countries, which API versions their SDK pin resolves to. That gap, between "what we use" and "what we'd find out about a schema or policy change in advance of the cutoff," is the entire reason silent-fail incidents land in production instead of in CI.

A 200 response on a call placement tells you the request was accepted. It doesn't tell you the call rang in Berlin.

If you'd been diffing Twilio's STIR/SHAKEN attestation field on calls to your top destination countries since the AU/BR rollout, you'd have caught the silent failure six weeks before the global cutoff — long enough to verify your numbers, port what needs porting, and refactor your ICF paths without scrambling.

That's the habit, and it generalizes to every voice provider, every regulator coalition, every API you don't control.

If your product runs voice through Twilio and you've already seen the regional silent-fail pattern, drop a reply with the country and the timeline. We're collecting these and the regulator coalition behind the rollouts looks bigger than the published list.

Twilio A2P 10DLC Campaign Registration Will 400 on June 30 — Two New Required Fields Most SaaS Apps Are Missing

FlareCanary — Thu, 07 May 2026 04:02:56 +0000

If your product sends SMS through Twilio in the United States, there's a Messaging Service campaign registered against your A2P 10DLC brand. On June 30, 2026, two new fields become required on every campaign registration: PrivacyPolicyUrl and TermsAndConditionsUrl. Submissions without them will return a hard 400 from Twilio.

This is the kind of change that doesn't break anything — until it does. Existing campaigns keep delivering messages. New campaigns and any update to a campaign hit the new validator the moment you touch it.

What's changing

Today, Twilio's A2P 10DLC campaign registration accepts campaigns without a privacy policy URL or terms-and-conditions URL on the campaign object itself. Brand-level URLs cover the carrier compliance story, and the campaign-level fields are technically optional.

After June 30, 2026:

PrivacyPolicyUrl is required on every new campaign registration
TermsAndConditionsUrl is required on every new campaign registration
Both URLs must resolve to publicly reachable HTTPS pages — Twilio fetches them as part of the registration check
The privacy policy must explicitly mention SMS data collection and that opt-in data is not shared with third parties
Terms must include the program's purpose, opt-out instructions ("STOP"), and the help keyword behavior ("HELP")

Submitting a campaign without either field after the cutoff returns:

HTTP 400 Bad Request
{
  "code": 21610,
  "message": "PrivacyPolicyUrl is required for campaign registration",
  "more_info": "https://www.twilio.com/docs/api/errors/21610",
  "status": 400
}

Same shape for TermsAndConditionsUrl. Same outcome: registration fails, the Messaging Service stays in a pending state, and SMS through that service won't deliver until you complete the registration with valid URLs.

What stays working — and what doesn't

The trap here is that this isn't a flag-day cutover for delivery. Existing campaigns that were registered before June 30 continue to send messages.

What breaks is anything that triggers a re-registration or update:

Creating a new Messaging Service for a new product, region, or environment
Adding a campaign to an existing brand — even programmatically via the Trust Hub API
Modifying campaign fields — message samples, use case, sample message frequency. Any PATCH against /v1/Campaigns/{sid} runs through the new validator.
Reapproving a flagged campaign — if a carrier flags a campaign for review (volume spike, content concern), the resubmission goes through the new schema.
Migrating between brands — moving a campaign to a different A2P brand requires a fresh registration.

The pattern is: anything you do to A2P 10DLC after June 30 has to satisfy the new fields, even if the underlying campaign was approved years ago. A team that hasn't touched A2P registration since 2024 might not even realize their internal tools assume the old schema.

The fix

Update your campaign registration code to always include both fields. The current Twilio Node.js SDK shape:

 await client.messaging.v1
   .services(messagingServiceSid)
   .usAppToPerson
   .create({
     brandRegistrationSid: 'BNxxxxxxxxxxxxxxxx',
     description: 'Order status notifications and shipping updates',
     messageSamples: ['Your order #1234 has shipped...'],
     usAppToPersonUsecase: 'MIXED',
     hasEmbeddedLinks: true,
     hasEmbeddedPhone: false,
+    privacyPolicyUrl: 'https://example.com/privacy',
+    termsAndConditionsUrl: 'https://example.com/terms',
   });

Same for the REST API directly — PrivacyPolicyUrl and TermsAndConditionsUrl are top-level form fields on POST /v1/Services/{sid}/Compliance/Usa2p.

Two things worth checking on the URLs themselves:

The URLs must be publicly reachable. Twilio fetches them server-side during registration. If they sit behind your auth layer, behind a staging-only domain, or only render with JavaScript, registration fails with a separate validation error that's worded like a generic "URL not accessible" message.
The privacy policy must mention SMS specifically. A generic site-wide privacy policy that doesn't reference SMS data collection or carrier opt-in handling can pass URL fetch but get rejected on content review by the carrier (T-Mobile is the strict one). The rejection arrives later, asynchronously, with a vague "campaign rejected by carrier" reason.

Why nobody's tests are going to catch it

This one fits the same pattern we keep seeing across our incident-intercept series, but with its own twist:

Unit tests don't catch it because the fields aren't required today. Tests pass against a sandbox that hasn't shipped the new validator yet. Twilio rolls staging changes ahead of production with usually a week or two of overlap, but the cutoff date itself isn't behind a feature flag — when it lands, it lands.

Integration tests don't catch it because most teams test message sending, not campaign registration. Registration happens once per Messaging Service, manually, often by a non-developer through the Twilio Console. There's no scheduled test that says "create a campaign and verify it accepts our payload."

The SDK doesn't catch it because the Twilio SDK doesn't enforce required fields client-side — it sends what you give it and lets the server validate. Adding a required: true to the Node.js typedef would help, but Twilio's typedefs lag the policy changes, and policy changes don't bump SDK majors.

Monitoring doesn't catch it because successful production message delivery doesn't exercise the registration path. Your Datadog dashboard will be green right up to the moment someone tries to add a new use case and the registration 400s.

Provisioning runbooks are where this hits hardest. Most teams have a runbook — code or wiki — for spinning up a new Twilio environment. That runbook captures the schema as it was the day it was written. If it was written in 2024 or 2025, it doesn't include these fields. The first person to use the runbook after June 30 will spend a confused hour figuring out why their carefully copy-pasted command 400s.

The carrier-rejection trap

Even when registration passes the Twilio API check, the campaign goes to the carriers (T-Mobile, AT&T, Verizon) for content review. T-Mobile in particular has tightened content review through 2025–2026, and they'll reject campaigns whose privacy policy doesn't:

explicitly state that SMS opt-in data is not shared or sold to third parties for marketing
include the program name and a description of the type of messages
specify message frequency ("up to N messages per month") or that frequency varies
list standard "Message and data rates may apply" language

Twilio's error in this case isn't a 400 on registration — registration succeeds. The campaign sits in a failed state hours later, and the API response surfaces a failure_reason that's frequently just "rejected by carrier" without specifics.

If your privacy policy is older than 2024 or hasn't been updated specifically for SMS, this is the more likely failure mode after June 30. Update both URLs and their content before the deadline.

How to actually catch this

For this specific change, three checks are worth setting up in May:

1. Audit your existing Messaging Services. Pull every Messaging Service and Campaign in your Twilio account and check whether privacy_policy_url and terms_and_conditions_url are set. The Twilio CLI:

twilio api:messaging:v1:services:list
twilio api:messaging:v1:services:compliance:usa2p:list \
  --service-sid MGxxxxxxxxxxxxxxxx

The compliance API surfaces the campaign object with both URL fields. Anything blank is a campaign that will fail re-registration.

2. Pre-stage the URLs on every brand. Even if you're not registering new campaigns, having the URLs ready and resolving means you can update existing campaigns in place before June 30 without scrambling.

3. Diff Twilio's response shape over time. Twilio's API responses include the campaign schema. The fields go from optional to required without an API version bump — but the OpenAPI spec, the SDK typedefs, and the response payloads all evolve. Watching for those diffs is exactly the kind of thing schema-drift monitoring is built for.

That third one is what we've been building at FlareCanary. Point it at the Twilio Trust Hub API endpoints you depend on, and it polls on a schedule, learns the expected structure, and flags when a field's nullability changes, when a new required field appears, or when an enum tightens. Severity-classified so noise stays low.

You don't need a dedicated tool. You can cron a script that hits the relevant Twilio endpoints, hashes the field set, and diffs. The point is that some layer has to be watching response shape, because the carrier compliance world doesn't bump versions when it tightens — it just tightens.

The harder question

This is the second Twilio incident we've covered in the series. The first was the regional domain deprecation (api.de1.twilio.com going dark on April 28, 2026). Both have the same shape: a long pre-announced cutoff, a real public docs page, and a failure mode that doesn't show up in your day-to-day delivery metrics until a specific provisioning or re-registration path runs.

Most teams know what their Twilio bill looks like. Almost none of them have a list of every Messaging Service in every Twilio account, with a flag for which ones have the new compliance fields populated. That gap — between "what we use" and "what we'd find out about a schema change in advance of the cutoff" — is the same gap we see for OpenAI, GitHub, Stripe, Shopify.

A 200 response on a message send tells you SMS is delivering. It doesn't tell you the next campaign you try to register won't 400.

If you'd been diffing the Twilio campaign registration schema against a baseline since the announcement, you'd have seen the field requirement land in staging weeks before the production cutoff — long enough to update every runbook and every IaC file before the deadline ever became a problem.

That's the habit, and it generalizes to every API you don't control.

If you've been hit by an A2P 10DLC change that broke a registration path you hadn't touched in months — drop a reply. We've been collecting these and the pattern across providers is remarkably consistent.

GitHub App installation tokens are getting longer in May 2026 — your VARCHAR(40) column is about to silently truncate them

FlareCanary — Wed, 06 May 2026 04:03:54 +0000

GitHub announced on April 24, 2026 that installation access tokens for GitHub Apps are changing format. Starting with a brownout mid-May 2026 and full cutover by late June 2026, tokens will grow from the current 40 characters (ghs_ + 36 chars) to up to roughly 520 characters. The prefix stays ghs_. The character set stays the same. Only the length changes — and only upward, and only sometimes.

That last part is the trap. During and after the rollout, some tokens will still be 40 chars (issued before the change, cached, returned by older Enterprise Server versions) and some will be 200, 380, 520. The same App, same installation, same call, on different days returns different lengths. There's no transition flag. There's no version header. The token still parses as bytes. It just doesn't fit anywhere you assumed it would.

The four shapes of the failure

# All four of these silently corrupt or reject valid tokens after May 2026.

# 1. Database column too narrow.
CREATE TABLE app_tokens (
    installation_id BIGINT,
    token VARCHAR(40),  -- silently truncates to 40 chars on insert
    expires_at TIMESTAMP
);

# 2. Regex validator pinned to old length.
TOKEN_RE = re.compile(r'^ghs_[A-Za-z0-9]{36}$')  # rejects new tokens
if not TOKEN_RE.match(token):
    raise ValueError("invalid token")

# 3. Length assertion in middleware.
assert len(token) == 40, f"expected 40-char token, got {len(token)}"

# 4. Fixed-size buffer in C/Go/Rust FFI.
char token_buf[64];  // overflows when memcpy'd, or strncpy truncates

The first three return 401 from GitHub with no helpful message — your code stored or transmitted a truncated/rejected token, GitHub rejected the truncated value, and the error trail goes cold one frame above the auth call. The fourth gets you a memory bug.

Why this is a quiet failure, not a loud one

Three reasons this rolls out as silent corruption rather than red-letter outage:

Type system unchanged. The token is still a string. Static analysis, schema validation, OpenAPI spec, type guards — all still pass. No compile error, no schema drift alarm. Octokit, PyGithub, go-github all return string from their token endpoints today and tomorrow.
Runtime unchanged at the issuance call. POST /app/installations/{installation_id}/access_tokens still returns 201 with a token field. Your code reads the field, uses it, gets a 401 on the next call — far from the issuance frame. A naive retry-on-401 hides it briefly, until the new token of the new size also fails to fit.
Brownout is intermittent. Per the GitHub announcement, the change rolls out as a brownout starting mid-May before full cutover late June. During the brownout window, the same token endpoint can return a 40-char token at 9:00am and a 380-char token at 9:30am. Tests written against a recorded fixture pass. CI passes. Production hits the brownout at unpredictable times.

Where to grep

Search every repo that touches a GitHub App for the four patterns:

# 1. DB column types
git grep -nE "token.*VARCHAR\(([0-9]+)\)" -- '*.sql' '*.ts' '*.py' '*.rb' '*.go'
git grep -nE "varchar\(40\)|VARCHAR\(40\)|String\(40\)" --

# 2. Regex validators
git grep -nE 'ghs_\[A-Za-z0-9\]\{[0-9]+\}|ghs_\\\w\{[0-9]+\}' --
git grep -n 'ghs_' -- '*.py' '*.ts' '*.go' '*.rb' '*.java' | grep -E 'match|regex|RE|Pattern'

# 3. Length assertions
git grep -nE 'len\(token\)\s*==\s*40|token\.length\s*==\s*40' --
git grep -nE 'fixed.*40|token\[0:40\]|substring\(0, 40\)' --

# 4. Fixed-size buffers
git grep -nE 'char token\[[0-9]+\]|\[40\]byte|token\[64\]' -- '*.c' '*.cpp' '*.go' '*.rs'

Common hiding spots beyond what grep catches:

Caching layers. Redis with MAXLEN, Memcached with item-size limits (default 1MB is fine, but custom-tuned smaller installs are not).
Audit logs. A token-redaction filter that masks the first 36 chars after ghs_ still leaks the last hundred characters of the new tokens.
Webhook signature verification. Code that uses an installation token in a downstream service's HMAC by hashing a fixed prefix length.
Environment variable storage. Some platforms truncate env vars over a length. Heroku, Vercel, Cloud Run all have limits per-platform; check your edition.
JWT claims. Apps that embed an installation token in a custom claim and the verifier asserts a fixed claim size.
Test fixtures. Recorded VCR cassettes, json fixtures, mock objects with hardcoded 40-char strings.

The most-bitten codebase is the one that wrote a Probot/Octokit-style validateToken helper years ago, copied a regex from a Stack Overflow answer, and forgot it existed.

Why VARCHAR(40) bites the hardest

Postgres and MySQL with strict mode raise an error when you try to insert a string longer than the column declared length — that's the good outcome, because the insert fails loudly and the call site gets the exception.

The bad outcome is what most production systems actually do:

MySQL with non-strict mode (the historic default before 5.7, and still common in older Docker images): silently truncates and emits a warning.
SQL Server with ANSI_WARNINGS OFF: silently truncates.
Some ORMs with default-string-conversion: do the truncation client-side before send.

The token gets stored at 40 chars. Reads return 40 chars. The auth call sends 40 chars to GitHub. GitHub rejects with 401. Your stack trace shows a 401 from POST /repos/.../check-runs — five layers away from the truncating column.

The fix is a column type change: ALTER TABLE app_tokens ALTER COLUMN token TYPE TEXT. There's no business reason to constrain token length at the storage layer; tokens are opaque to your app.

The migration that doesn't migrate cleanly

The obvious fix — widen all the columns, drop all the regexes, remove all the assertions — is correct end-state but introduces a window in the middle where the new tokens land in code paths that also still have stale references to the old format.

Three places this bites:

Reverse proxies and middleware. A Cloudflare Worker or Express middleware that strips/validates tokens. If you update the App but not the Worker, the Worker rejects valid tokens.
Cross-service token forwarding. Service A fetches a token, hands it to Service B, B logs and validates the format. Updating only A means B starts dropping tokens it gets from A.
CI/CD secret scanning. Internal secret scanners that pattern-match on ghs_[A-Za-z0-9]{36} will stop catching leaked tokens after the format change, because the regex no longer matches the new format. Update the scanners or you have a leak detection regression at the same time as the migration.

The order to roll: scanner regexes first (they need the broadest pattern, ghs_[A-Za-z0-9]+), then storage layer, then validators and assertions. The App itself needs no change — Octokit and friends will get the new tokens automatically once GitHub starts issuing them.

What "broadest pattern" means for the regex

Don't anchor on the new max length (~520) either; that's a current ceiling that GitHub may move again later. Anchor only on the prefix and character set:

# Wrong — pins to current new ceiling
TOKEN_RE = re.compile(r'^ghs_[A-Za-z0-9]{36,520}$')

# Right — accepts anything matching prefix and charset
TOKEN_RE = re.compile(r'^ghs_[A-Za-z0-9]+$')

If you actually need a length constraint for a defensive reason (e.g., a sanity check before storing), set a generous upper bound — 4096 is a reasonable belt-and-suspenders ceiling that won't bind on a future format change.

What's not changing

Prefix. Still ghs_. (Personal access tokens use ghp_, OAuth tokens gho_, app-to-server ghu_. None of these are announced as changing in this rollout, but the same lessons apply if they do later — strip your fixed lengths now.)
Issuance API. POST /app/installations/{installation_id}/access_tokens returns the same JSON shape.
Revocation API. DELETE /installation/token still works the same way.
Token TTL. Still 1 hour from issuance.
Permissions model. Unchanged.

Minimum-viable fix

git grep the four patterns above (column type, regex, length assertion, fixed buffer). Inventory every match.
Update DB columns to TEXT (or equivalent unbounded string type). For MySQL specifically, drop indexes on the token column before changing type if you have any — the index becomes invalid after the change.
Replace fixed-length regexes with prefix-only validation (^ghs_[A-Za-z0-9]+$) or remove the validation entirely (tokens are opaque, your code shouldn't be parsing them).
Remove length assertions in middleware and FFI boundaries. Resize fixed-size buffers to a generous ceiling (1024 or 4096).
Update internal secret scanners first — before any token-handling change — so leak detection doesn't regress mid-migration.
Add a real integration test against POST /app/installations/{id}/access_tokens and assert that the returned token round-trips through your storage layer without modification (use a length-comparison check, not a string-equality check, to keep the test stable across token issuances).
If you operate GitHub Enterprise Server, plan for the format change in your next GHES upgrade — the brownout schedule for GHES typically lags the GitHub.com schedule by one or two minor versions.

The pattern this fits

Token format changes are the canonical silent-fail. The type system sees a string. The schema sees a string. The contract test sees a string. The thing that breaks is an assumption about the string's shape — and assumptions don't show up in any contract.

GitHub has done this before (the token format change in 2021 introduced the ghp_, ghs_, etc. prefixes), and the same shape of breakage rolled out then: VARCHAR columns silently truncating, regex validators silently rejecting, fixed-buffer assertions overflowing. The fix five years ago was the same fix today: don't constrain the storage size, don't validate the format past the prefix, don't bake assumptions about token shape into anything except the issuance call itself.

If you're treating an opaque token as anything more structured than "an opaque blob from GitHub that is at most a few KB," you're carrying a latent bug that will trip on the next format change after this one.

FlareCanary monitors REST APIs and MCP servers for schema drift. Free tier covers 5 endpoints with daily checks.

Forem: FlareCanary

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

String operations

JSON serialization

Mixed-type arithmetic

Database driver type expectations

Logging and observability tools

The Wire-Format Trap

Why The Migration Slipped

A Migration That Actually Holds

How To See The Next One Coming

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

The exact shape change

The four places this breaks

The deeper twist: the field was always shadowing core

The migration

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

The pattern across these GitHub deprecations

Action items, in order, before May 19

Twilio's Transit CallerID Sunset on May 31 — Your Voice Flows Already Look Broken in Six Countries and You Probably Don't Know

What Transit CallerID is, and what's changing

The silent-fail mode that gets under everyone's monitoring

Where to look for the truth

The migration paths

1. Static CallerID — use Verified CallerID

2. Dynamic CallerID where you control all the lines — port them to Twilio

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`