DEV Community: FlareCanary

Shopify Scripts stop executing June 30 — and the failure is silent: checkout completes at full price, no error

FlareCanary — Sat, 13 Jun 2026 05:00:46 +0000

On June 30, 2026, every Shopify Script stops executing. This is the final deadline — it has already been pushed twice (August 2024 → August 2025 → June 2026), and Shopify has stated this one is firm. Editing and publishing new Scripts was already turned off on April 15, 2026.

Most "deadline" posts about this frame it as a migration-project problem: audit your Scripts, rebuild them as Functions, ship before the date. That's true. But it buries the part that actually bites.

Here is the part that makes this dangerous.

When a model gets retired — Imagen, an OpenAI snapshot, a Grok slug — the failure is loud. The call returns an error, your pipeline throws, someone gets paged. Loud failures get fixed.

A Shopify Script ceasing to execute is not loud. There is no Script to call and fail. The checkout simply runs without it. The customer reaches the thank-you page. Shopify returns a completed order. Your logs show a successful checkout. Everything is 200 OK.

The only thing missing is the logic the Script was doing — and nothing in the system says so.

1. The cutoff itself fails silent — checkout just stops applying your rules

Think about what Shopify Scripts actually do. They are Ruby scripts that run inside checkout to modify three things:

Line item discounts — "20% off for wholesale-tagged customers," "buy 3 get 1 free," tiered volume pricing.
Shipping rates — hide express shipping for PO boxes, rename rates, discount freight for VIPs.
Payment methods — hide credit card for high-risk carts, hide cash-on-delivery above a cart threshold.

On July 1, none of that runs. And checkout does not error — it has nothing to error about. It just renders the cart without the Script's modifications:

The wholesale customer who should see 20% off pays full price. No error. Order completes.
The express shipping you hid for PO boxes shows up again, gets selected, and now you owe a carrier for a route you can't service.
The payment method you hid on high-risk carts comes back, and the fraud you were screening out walks straight through.

Every one of these is a 200, a completed order, a happy-looking checkout funnel. You will not find this in an error dashboard, because there is no error. You find it in a margin report three weeks later, or in a customer support ticket, or in a chargeback.

That is the worst kind of failure: revenue logic that silently switches off while the system around it reports success. If you have a Script live today, June 30 is not a migration deadline — it is the day a piece of your checkout silently changes behavior.

2. A deployed Function does nothing until a discount node exists in the Admin

So you migrate. You rebuild the Script as a Shopify Function — WebAssembly, the official replacement. You write the logic, npm run deploy, the Function shows up in your Partner Dashboard. Done?

No. And this is the trap that catches teams who think a Function is a drop-in for a Script.

A Script ran the moment it was saved in the Script Editor. A Function does not run just because it is deployed. A discount Function only executes when a discount is attached to it — a DiscountAutomaticApp or DiscountCodeApp node, created in the Shopify Admin (or via the discountAutomaticAppCreate GraphQL mutation) and set to Active.

Deploy the Function, forget to create the discount node — or create it and leave it in Draft, or with a future start date — and the result is exactly the same as section 1: checkout runs, completes, charges full price. The Function exists. It is just never invoked. There is no error, because nothing called anything.

This is the half-migration failure mode. The Script is gone, the Function is "deployed," the dashboard looks green, and discounts are silently off. Confirm the discount node exists, is Active, and has a start date in the past. The Function is only half the wiring.

3. The input query: a field you forget to request comes back `null`

Scripts and Functions receive cart data completely differently, and this is where logic silently no-ops.

A Ruby Script got the whole cart handed to it — Input.cart.line_items, customer, tags, everything in scope. A Function gets only what its input query explicitly asks for. The input query is a GraphQL document you write; Shopify runs it and passes the result to your Function as JSON.

The rule that bites: a field you do not request in the input query is null in your Function. Not an error. Not a warning. null.

So you migrate a Script that gives a discount to customers tagged wholesale. In the Function you write the discount logic correctly — but your input query doesn't request cart.buyerIdentity.customer.hasTags (or the metafield, or the product tags, or the line-item sellingPlanAllocation, whatever your rule keys on). The Function runs. It reads the customer tags. They are null. The null doesn't match wholesale. It returns "no discount."

200 OK. Order completes. Full price. The Function ran successfully — it just made its decision on data that was silently absent. Every conditional discount you migrate has this exposure: the condition you branch on must be in the input query, or your branch quietly takes the wrong path.

When you migrate a Script, write down every field its logic reads, and check each one is in the input query. The dangerous field is the one your logic depends on and your query forgot.

4. `combinesWith` and discount strategy: a Script that always applied may now lose

A Script applied its discount unconditionally — the Ruby ran, the discount landed, end of story. A Function discount does not get that guarantee. It lives under two layers of Shopify-side arbitration that Scripts never had:

combinesWith is configured on the discount node, not in your Function code. It declares whether this discount can stack with order / product / shipping discounts. If you had a Script that gave both a line-item discount and an order-level discount, and you rebuild it as two Functions whose discount nodes are not configured to combine with each other — only one applies. The other is silently dropped. Your Function code is correct; the node configuration is the bug.
discountApplicationStrategy decides which discount wins per line item — FIRST, MAXIMUM, or ALL. A Script that always stacked its discount on top may become a Function that only applies when it is the best discount on that line. On a cart that already has a better discount, yours silently does not apply.

None of this errors. The checkout completes, an order is created, a discount may even show — just not the combination your Script produced. If your Script's behavior depended on stacking, your Function's behavior now depends on the node config and the strategy matching it. Verify both against a real multi-discount cart.

One more: if you are following an older tutorial, make sure you build against the unified Discount Function API, not the legacy split Order Discount / Product Discount Function APIs — those are themselves deprecated. Migrating onto an already-deprecated target is a migration you get to do twice.

What to actually do

Inventory your Scripts now. In the Shopify admin, open the Script Editor (Apps → Script Editor) and the Shopify Scripts customizations report. List every live Script and exactly what it modifies — discount, shipping, or payment.
For each Script, decide the replacement explicitly. A Shopify Function, a public app from the App Store, or consciously dropping it. The danger is the Script nobody owns — it just stops on June 30 and no one is watching the metric it moved.
Treat "deployed" and "live" as two different states. For every discount Function: confirm the discount node exists, is Active, has a past start date, and has combinesWith set to match the stacking your Script did.
Diff the input query against the Script's logic. Every field the Ruby read must be in the Function's input query. Anything missing is null, and null silently changes which branch your discount logic takes.
Test on real carts before June 30, not after. Build the carts your Scripts actually targeted — the wholesale customer, the PO box address, the high-risk payment cart, the multi-discount cart — and run a full checkout. Confirm the final price, the shipping options, and the payment methods match what the Script produced. This is the only check that catches a silent no-op.
Watch the margin metric across the cutover. Average discount per order, blended shipping cost, payment-method mix. If a Script silently stops, these move before any human notices. A dashboard line is cheaper than a chargeback.

The model retirements get headlines because they fail loud. Shopify Scripts will fail quiet — checkout will keep completing, orders will keep flowing, and the only signal that something broke is a number in a report moving the wrong way. Plan for the quiet failure.

FlareCanary watches your third-party APIs and SDKs for breaking changes like this one — deprecations, response-shape changes, and silently-dropped behavior — and surfaces them before they reach production. Free tier monitors 5 endpoints.

Google retires every Imagen model on June 24 — and the Gemini image migration fails silently in 4 places

FlareCanary — Wed, 10 Jun 2026 05:00:36 +0000

On June 24, 2026, Google shuts down every remaining Imagen model on the Gemini API:

imagen-4.0-generate-001
imagen-4.0-ultra-generate-001
imagen-4.0-fast-generate-001

(imagen-3.0-generate-002 already went dark on November 10, 2025 — if you somehow survived that one, you were already on borrowed time.)

The recommended replacement is gemini-2.5-flash-image — the model Google markets as "Nano Banana" — or gemini-3-pro-image-preview.

Here is the part that makes this dangerous. The retirement itself is loud: after June 24, a request to imagen-4.0-generate-001 returns an error, your pipeline throws, someone gets paged. That's fine. Loud failures get fixed.

The migration is not loud. Imagen and Gemini's image generation are not the same API with a different model string — they are two different request shapes, two different endpoints, and two different parameter vocabularies. And Gemini's image endpoint will happily accept a request full of Imagen-era parameters, ignore the ones it doesn't recognize, and return 200 OK with an image. Not the image you asked for. An image.

That's the trap. Teams will migrate under deadline pressure, see images come back, see green status codes, and ship. The defects land downstream, weeks later, with no error attached.

Here's the silent-fail surface.

1. The endpoint and response shape changed — and a half-migrated parser fails quiet

Imagen runs on the :predict endpoint. You send instances and parameters, and you get back:

{ "predictions": [ { "bytesBase64Encoded": "...", "mimeType": "image/png" } ] }

Gemini image generation runs on :generateContent. You send contents with parts, and the image comes back at:

{ "candidates": [ { "content": { "parts": [ { "inlineData": { "data": "...", "mimeType": "image/png" } } ] } } ] }

If you point your code at the new model but keep calling :predict, you get a loud error — good. But the failure that actually ships is the half migration: you move to :generateContent, and a downstream helper still reaches for response.predictions[0].bytesBase64Encoded.

That path doesn't exist on a Gemini response. In JavaScript it evaluates to undefined. In Python it's a KeyError only if you index hard — and most image-handling code doesn't, because it was written defensively:

img = resp.get("predictions", [{}])[0].get("bytesBase64Encoded")
if img:
    save(img)

predictions is missing, so img is None, so the if is skipped. No exception. No image written. 200 OK logged. The function returns cleanly. You find out when someone notices the asset bucket stopped filling — and by then you can't tell which day it started.

2. `sampleCount` is gone — your batch silently collapses to one image per call

This is the sharpest one.

Imagen's :predict request takes a sampleCount parameter: ask for up to 4 images in a single call (imagen-4.0-generate-001), or 1 at a time on the Ultra tier. Plenty of pipelines lean on this — generate 4 candidates per prompt, score them, keep the best. The sampleCount: 4 is load-bearing.

Gemini's image API has no sampleCount. It generates one image per call, and Google's own documentation is blunt about it: "The model won't always follow the exact number of image outputs that the user explicitly asks for."

So when your migrated request carries sampleCount: 4 — or you ask conversationally for "four variations" — Gemini doesn't error. It returns one image, 200 OK. Your candidate pool just dropped from 4 to 1. The "pick the best of 4" step still runs; it's now picking the best of 1. Output quality quietly degrades, throughput math is off by 4×, and nothing in the response says "you asked for four and got one."

If any part of your system reasons about how many images it gets back, that assumption is now wrong, and it's wrong silently.

3. Aspect ratio moved namespaces — and became a suggestion

Imagen takes aspectRatio as a top-level entry in parameters, and it's a hard constraint: ask for 16:9, get 16:9.

On Gemini image generation, aspect ratio is not a top-level parameter. It lives nested inside an image-config block on the generation config. Carry the Imagen-style top-level aspectRatio field straight over and it lands nowhere — it's an unrecognized key, silently dropped, and Gemini falls back to its default (square, or whatever it infers from the prompt).

Result: 200 OK, a perfectly valid image, in the wrong dimensions. Every downstream consumer that assumed a fixed aspect ratio — a CSS grid, a video frame, a thumbnail cropper, a print layout — now gets a shape it wasn't built for. Best case it looks wrong. Worst case the cropper "fixes" it by cutting the subject's head off, automatically, with no error.

And even when you do nest the field correctly, treat it as a strong hint rather than a guarantee. There are documented reports of Gemini image models returning a 1:1 square for an explicit 16:9 request. Validate the dimensions of what comes back; don't trust that you got what you asked for.

4. `personGeneration` has no clean equivalent — your safety posture shifts without a diff

Imagen exposes a personGeneration parameter: dont_allow, allow_adult, allow_all. Teams set this deliberately — a kids' education product pins dont_allow; an internal tool runs allow_all. It's a compliance decision, often written down in a review somewhere.

Gemini's image API doesn't have a personGeneration knob in that shape. It folds people-generation behavior into the general model safety stack. So personGeneration on a migrated request is — you'll notice the pattern by now — an unrecognized key, silently dropped.

What you're left with is Gemini's default people-generation behavior, which is not guaranteed to match the Imagen setting you carefully chose. A pipeline pinned to dont_allow may start returning images with people in them. A pipeline that relied on allow_all may start refusing prompts it used to honor. Either way, 200 OK, no warning, and a safety/compliance posture that changed without anyone editing the line that used to control it. This is the surface a security review would actually care about, and it has no error and no schema diff to catch.

5. The two things to also budget for

Prompt rewriting. Imagen runs an LLM-based prompt rewriter by default — it silently expands your terse prompt before generating. Gemini handles prompts natively and differently. Migrate, send the byte-identical prompt, and the image style, composition, and detail level shift — because the prewriting layer your results were implicitly tuned against is gone. Nothing breaks; your outputs just drift. If you have a brand or style baseline, re-approve it after migrating.

Mask-based editing has no replacement. This is the migration some teams can't actually make. Imagen's capability/editing model does precise, programmatic mask-based inpainting and outpainting — you supply a reference image plus a mask, and edits land exactly inside the mask. Gemini 2.5 Flash Image does conversational editing: you describe the change in words. There is no pixel-precise mask parameter. If you have a pipeline that does deterministic mask-driven edits — product photography, automated retouching, compositing — there is no drop-in path. Find this out now, in June, not in a sprint planning meeting in July.

What to actually do

Grep for the dead model IDs across everything — app code, IaC, notebooks, prompt configs, batch-job definitions:

   git grep -nE "imagen-(4\.0-(generate|ultra-generate|fast-generate)-001|3\.0)"

Treat this as a rewrite, not a string swap. The endpoint, request shape, and response shape all change. Budget for it like the API migration it is.
Audit every Imagen-era parameter against the new API. Make a literal checklist: sampleCount, aspectRatio, personGeneration, prompt-rewrite behavior. For each, confirm it either has a real equivalent you've wired up, or accept — explicitly, in writing — that you're losing it. The danger is the parameter you neither migrate nor consciously drop.
Assert on the response, don't assume it. After migrating, check the count of images returned and the dimensions of each one against what you requested. Both can silently differ. A three-line assertion catches sections 2 and 3 of this post.
Re-approve your output baseline. Prompt rewriting is gone and the underlying model is different. Whatever "looks right" meant for your product, re-establish it against real Gemini output before June 24 — not after.

The model retirement is the loud part, and the loud part will get handled. The migration is the quiet part. Plan for the quiet part.

FlareCanary watches your third-party APIs and SDKs for breaking changes like this one — model retirements, response-shape changes, and silently-dropped parameters — and surfaces them before they reach production. Free tier monitors 5 endpoints.

Atlassian Admin v1 APIs Go Dark on June 30 — Your User-Provisioning Script Probably Hits Eleven of Them

FlareCanary — Sun, 07 Jun 2026 05:00:42 +0000

If your team has any custom Atlassian Cloud admin automation — IdP sync, SCIM glue, lifecycle scripts, group provisioning — it almost certainly hits at least one of the eleven endpoints under /admin/v1/orgs/{orgId}/.... After June 30, 2026, those endpoints are gone.

Atlassian announced the v1 sunset alongside the new v2 Directory/Users/Groups APIs. The migration is documented; the part that isn't documented loudly is that v2 isn't a drop-in path swap. The shape of the URL changed, the auth model picked up an extra resolution step, and several common automation patterns become two-call sequences instead of one.

The eleven endpoints to grep for

User-management endpoints going away:

POST /admin/v1/orgs/{orgId}/users/search
POST /admin/v1/orgs/{orgId}/directory/users/{accountId}/suspend-access
POST /admin/v1/orgs/{orgId}/directory/users/{accountId}/restore-access
DELETE /admin/v1/orgs/{orgId}/directory/users/{accountId}

Group-management endpoints going away:

POST /admin/v1/orgs/{orgId}/groups/search
POST /admin/v1/orgs/{orgId}/directory/groups
DELETE /admin/v1/orgs/{orgId}/directory/groups/{groupId}
POST /admin/v1/orgs/{orgId}/directory/groups/{groupId}/roles/assign
POST /admin/v1/orgs/{orgId}/directory/groups/{groupId}/roles/revoke
POST /admin/v1/orgs/{orgId}/directory/groups/{groupId}/memberships
DELETE /admin/v1/orgs/{orgId}/directory/groups/{groupId}/memberships/{accountId}

Plus POST /admin/v1/orgs/{orgId}/users/invite, which Atlassian deprecated on January 13, 2026 — same June 30 sunset date.

A literal grep on your repo:

grep -rn "admin/v1/orgs" --include="*.{py,js,ts,go,rb,sh}" .

If anything comes back, it dies on June 30.

This affects any tenant on centralized user management — which, since 2025, has been the default for new orgs and the migration target for existing ones. If you don't know which user management mode your org is on, the v1 sunset still applies once the migration completes, so treat it as in-scope.

What v2 actually looks like

The v1 path was organization-rooted:

/admin/v1/orgs/{orgId}/directory/users/{accountId}

The v2 path is directory-rooted under an organization:

/admin/v2/orgs/{orgId}/directories/{directoryId}/users/{accountId}

That directoryId is not optional, and Atlassian's v1 callers never had to know it. Every script migrating off v1 needs an extra step to discover the directory before it can act on a user or group inside that directory.

So a one-call workflow becomes a two-call workflow:

1. List directories for the org → pick a directoryId
2. Call the v2 endpoint with {orgId}/directories/{directoryId}/...

For orgs with one directory, this is mostly mechanical. For orgs with multiple directories (Identity Manager, Google, Microsoft, plus a local directory), every script now has to disambiguate, and "the right one" depends on which IdP the user came from.

OAuth scopes — one easy miss

The Admin scope set didn't get a new "v2 scope." But scripts that previously only operated on users-by-account-id never had to declare read:directories:admin. Now they do, because every v2 call passes through a directory resolution.

Apps that don't add read:directories:admin to their token request will get scope errors on the new endpoints — without the v1 endpoint being there to fall back to. The scope error happens at request time, not at auth time, so a token issued before the migration looks fine until the first call.

What the failures will look like

Atlassian's announcement says v1 endpoints "will remain available until 30 June 2026. After this date, they will be fully deprecated." The exact response shape post-sunset isn't documented for /admin/v1/orgs/..., but Atlassian's pattern on other removed REST APIs (Jira /rest/api/3/search and friends) has been HTTP 410 Gone with a JSON error along the lines of:

{
  "code": 410,
  "message": "The requested API has been removed. Please use the newer endpoints."
}

That's the expected fingerprint, not a guarantee. If your client treats 410 as terminal (most retry libraries do), the failed call will not be retried, and the operation — suspend, remove, group-add — silently won't happen. The script returns "successful" on the calls that didn't go through the dead endpoint and "failed" on the ones that did, and a half-completed offboarding looks identical to a successful one in the audit log.

The use cases that quietly break

The Atlassian announcement explicitly calls out a handful of automation patterns that depend on the v1 endpoints:

Offboarding scripts. Calling suspend-access and then directory/users/{accountId} DELETE in sequence is the canonical Atlassian-side termination flow. Both endpoints are on the list.
SCIM-adjacent IdP sync. Many teams wrote custom sync because Atlassian's SCIM connector didn't cover their IdP, or didn't handle group memberships the way they wanted. Custom sync scripts overwhelmingly use the v1 group memberships endpoints.
Bulk invite onboarding. POST /admin/v1/orgs/{orgId}/users/invite was the canonical way to invite a list of users with a default group set. Already deprecated since January.
Group provisioning from CI. Terraform-style "groups defined in code" pipelines that create/delete groups based on YAML — the create and delete endpoints are both on the list.

The offboarding case is the one that goes wrong silently. A user gets removed from your IdP, the sync script runs, the v2 path fails because the script wasn't migrated, and the user keeps their Atlassian access until someone notices on the next access review. That's the nightmare scenario for security teams who track "removed in IdP within X hours" as a compliance metric.

What to do this quarter

Three steps:

Inventory. Grep admin/v1/orgs across all internal repos, CI configs, and scripts on admin/ops machines. Capture which endpoints are in use.
Resolve directory IDs. Build (or buy) a small helper that lists directories on the org and returns the directory ID for a given user — every v2 call needs this.
Add the read:directories:admin scope to your token requests before you migrate the calls. The scope addition is forward-compatible with v1 calls, so you can add it without breaking anything before you cut over.

If your custom sync also uses Jira's /rest/api/3/search or any other v3 Jira API marked for removal, batch them — same orgs, same teams, same maintenance window.

The pattern here is the one we keep seeing across providers: a deprecation notice goes out, the SDK or admin script gets an "available until" date that everyone marks on a sticky note, and on the day the API returns 410 the team finds out which scripts they actually shipped to production years ago. We built FlareCanary to flag the response-shape and field-semantic changes that don't even show up as a deprecation notice — but on this one, the calendar entry for June 30, 2026 is the one to set.

If your offboarding flow uses any v1 endpoint, treat it as the highest-priority migration. Half-completed user removals are an audit problem long before they're a security problem.

Auth0 removes enabled_clients from connection reads July 13 — Terraform/Pulumi will silently see every client as disabled

FlareCanary — Thu, 04 Jun 2026 05:00:42 +0000

If you manage Auth0 connections through Terraform, Pulumi, or any in-house multi-tenant provisioning script, there's a quiet failure mode landing on July 13, 2026. On that date, Auth0 removes the enabled_clients field from GET /api/v2/connections and GET /api/v2/connections/{id} responses, and stops accepting enabled_clients in PATCH /api/v2/connections/{id}. The field was deprecated January 13, 2026; July 13 is end-of-life.

Nothing returns an error. Calls still get a 200. The connection object comes back, with all the same fields you've always read — minus one. The code that reads connection.enabled_clients to figure out which apps are wired to a connection gets either an empty array or undefined, depending on how Auth0 serializes the absence. Either way, your IaC plan, your drift-detection job, or your client-provisioning script reads "no clients enabled" and reacts accordingly. That reaction is usually one of two failure modes, both bad.

The Two Silent Failure Modes

Mode 1: Drift-detection wipe

Terraform's auth0_connection resource (and the Pulumi equivalent) include enabled_clients as a managed attribute. On every plan, the provider calls GET /api/v2/connections/{id}, reads the current enabled_clients, and compares it to what's in your state file. After July 13, the read returns empty, the state file still lists the configured set, and the provider sees a delta. Then apply calls PATCH to "fix" it — sending the configured enabled_clients list back. The PATCH ignores the field (it's deprecated for input too), the connection's client associations stay whatever they actually are, and the next plan shows the same drift again.

The dangerous variant: if you've ever managed Auth0 partly through Terraform and partly through the dashboard or a separate provisioning tool, your state file lists only the clients Terraform knows about. A drift-detection run that decides "the source of truth is my state file" — common in CI pipelines that auto-apply — will silently issue a corrective change. Until July 13, that worked: PATCH with the desired enabled_clients reconciled the difference. After July 13, the PATCH silently no-ops, so Terraform-managed connections look right in the state but actually still have the out-of-band associations intact. If you then also run the new endpoint-based code to "clean up disabled clients," you can wipe the out-of-band ones.

Mode 2: Multi-tenant provisioning over-restriction

A common multi-tenant pattern in SaaS apps that white-label Auth0: when a new tenant signs up, your control plane creates an Auth0 client for them and enables existing connections for that client. The reverse — enumerating which connections each client is enabled on — is usually done by walking all connections, reading enabled_clients, and filtering by the tenant's client_id.

After July 13, that walk returns empty enabled_clients for every connection. Code that interprets the empty list as "this connection has no enabled clients" and then "remediates" by re-enabling everything from a desired-state list hits either:

A no-op (the PATCH ignores the field, the actual associations don't change, the tenant works fine in production but every audit report says they're disabled).
A retry storm (if the script keeps trying to re-enable until GET confirms the change, which never happens because the field is gone).

Either way, observability dashboards keyed on enabled_clients go dark or flatline. SCIM-style sync jobs that reconcile Auth0 against an external IdP source-of-truth start over-eagerly trying to fix a discrepancy that isn't real.

What Actually Changed

The new endpoints, available now:

GET /api/v2/connections/{id}/clients — returns the enabled clients for a connection, paginated.

{
  "clients": [
    { "client_id": "abc123..." },
    { "client_id": "def456..." }
  ],
  "next": "opaque_cursor"
}

Query params: take (1–1000, default 50), from (cursor; omit on first call). When next is absent in the response, you've walked the full set. Required scope: read:connections.

PATCH /api/v2/connections/{id}/clients — toggle enabled status for specific clients.

[
  { "client_id": "abc123...", "status": true  },
  { "client_id": "def456...", "status": false }
]

Returns 204 No Content on success. Required scope: update:connections. The hard constraint that bites bulk operations: maximum 50 clients per request. If your provisioning code enables a connection for all 200 clients in a tenant batch via one enabled_clients PATCH today, the equivalent through the new endpoint is four sequential calls. Naive ports that don't chunk silently truncate at 50 (or, depending on the API, return 400 — the docs don't pin this down).

The new PATCH is also selective, not replacing. The old enabled_clients was a full-set replacement: PATCH with ["client_a", "client_b"] made those exactly the enabled set. The new endpoint only toggles the clients you list. Anything not in your PATCH array keeps its current status. Tools that assumed PATCH = full replacement will now leave stale enables in place.

Why It Slips Through Normal Detection

Walk the standard checks:

HTTP status check — passes. GET /api/v2/connections/{id} still returns 200. The connection object is still there, just without the enabled_clients key.
Schema validation — passes. enabled_clients was always an optional field for connections that hadn't been wired to any client yet. A response without it is structurally valid.
Terraform plan — thinks it caught it. The provider sees the configured enabled_clients is no longer present in the remote state and shows a diff. The diff says "will add three clients." apply runs, the PATCH succeeds (200, the deprecated field is silently dropped), and the next plan shows the same diff. To an operator, this looks like Terraform fighting with another process — not like a deprecated field.
CI / unit tests — pass if they mock Auth0. Anyone who tests against a recorded fixture from before July 13 sees the same field they always saw. Tests don't notice until they hit real Auth0.
Migration audits — only catch it if you specifically look for enabled_clients in your codebase. Most audits look for endpoint URL changes, not field-level removals.

The Terraform Auth0 provider will probably ship a release that switches enabled_clients to use the new endpoints under the hood — but the release calendar isn't Auth0's, it's HashiCorp's (or the community maintainers'). Pinning to an older provider version with explicit enabled_clients config delays the migration into the deprecation window without addressing it.

How To Detect It Now

1. Grep for enabled_clients across your infra repos. Every match is a migration site:

Terraform auth0_connection resources with enabled_clients = [...]
Pulumi auth0.Connection resources with enabledClients: [...]
Direct API calls — anything reading .enabled_clients off a connection response, or sending enabled_clients in a PATCH body
SDK calls: managementClient.connections.update(..., { enabled_clients: ... }) in node-auth0 / auth0-python / auth0.net

2. Verify the new endpoints work for your scopes. The new GET /api/v2/connections/{id}/clients requires read:connections, which most existing M2M tokens already have. The PATCH requires update:connections. If you've used a scoped-down token in CI that only had read:client_grants or similar, you may need to expand it.

3. Chunk PATCHes by 50. Wherever you currently send a full enabled_clients array, the replacement code has to enumerate the desired client_ids, diff against the current set (paginated via the new GET), and issue PATCH /clients calls in chunks of 50 with status: true / status: false per client. Bulk operations that don't chunk break.

4. Treat missing enabled_clients as a sentinel during migration. If your code path can run before or after July 13 (a slow CI matrix, a paused tenant, a long-lived M2M token still hitting an older runtime), add an explicit check: if enabled_clients is undefined on the connection response, fall back to the new endpoint instead of treating it as "no clients enabled." That single guard makes the cutover safe regardless of which side of July 13 the call lands on.

The Pattern

A vendor moves a piece of state from "inlined on a parent resource" to "dedicated sub-resource endpoints." The parent endpoint keeps working. The field just stops being there. Code that assumed presence of the field as "this connection has clients" and absence as "this connection has no clients" reads the new absence as the old "no clients" — and acts on it.

The same shape shows up across cloud providers and SaaS APIs every few months. The mitigation isn't to track every deprecation memo; it's to treat field absence as ambiguous (was it removed? was it always empty? was it filtered out by a scope?) and require an explicit signal before reacting. After July 13, "absent" on Auth0 connection responses means "go ask the new endpoint" — not "no clients enabled."

If you run Auth0 through IaC, the cheapest move this month is to grep for enabled_clients, write the new-endpoint reads alongside the old-field reads, and gate the cutover on a feature flag you can flip per-environment. Eight weeks of runway is enough to do it carefully; the alternative is debugging silent drift on a Monday in July.

Shopify Changed heldBy From a String to an Object in 2025-01 — Your Query Still Returns 200 OK

FlareCanary — Mon, 01 Jun 2026 05:00:36 +0000

Shopify ships a new GraphQL Admin API version every quarter. Most releases are additive. A few are not. The 2025-01 release is one of the "are not": it removed a handful of fields that thousands of apps were reading, and it quietly changed the type of one of the most common fulfillment fields from a string to an object.

The endpoint still returns 200 OK. The query still parses. The field your code reads just isn't there anymore — or it's there under a new name with a completely different shape.

If you upgraded a Shopify app from 2024-x to 2025-01 without reading the full release notes and you're seeing "this field is empty now" in production, this is probably why.

The heldBy → heldByApp Change

On a FulfillmentHold object, the 2024-x GraphQL schema returned:

{
  fulfillmentHold {
    heldBy  # String! — "PrepSupport" or "ShopifyFulfillmentNetwork" or an app name
  }
}

As of 2025-01, heldBy is gone. In its place:

{
  fulfillmentHold {
    heldByApp {
      title    # String! — "PrepSupport"
      id       # ID!
    }
  }
}

The 2025-01 release notes put it like this:

If you currently query fulfillmentHold.heldBy, then transition to querying fulfillmentHold.heldByApp.title.

The important thing is what happens if you don't. GraphQL in this version will happily return null for a field it no longer recognizes (depending on your client's error handling), or it will throw a field-level error that your resolver swallows. Your downstream code — the logic that routes held orders to a human, the Slack notification that names the blocking app, the dashboard tile that shows "held by X" — starts quietly producing empty strings or "Unknown."

Type systems don't save you here, either. Most Shopify SDKs are either hand-rolled TypeScript types generated from the schema at some pinned version, or they're any-shaped because the developer didn't codegen against the current version. If your schema snapshot is from 2024-10, heldBy is still in your types, your IDE still autocompletes it, and your unit tests (mocking your own types) pass. The mismatch only shows up at runtime, against Shopify's live API.

PrivateMetafield Is Just Gone

The second big removal in 2025-01:

PrivateMetafield is removed from the public GraphQL Admin API. Use app-data metafields instead.

There is no field rename, no transitional alias, no "deprecated for N versions" wind-down. Every query, mutation, and resolver that referenced PrivateMetafield, privateMetafields, privateMetafieldUpsert, or the MetafieldStorefrontVisibility object stops working.

If your app was using private metafields to store per-shop configuration — credentials, feature flags, per-merchant routing rules — that configuration didn't move anywhere. You have to migrate it to app-data metafields yourself, re-grant access via the new app-reserved namespace scheme, and replace every read and write. And until you do, the queries come back empty.

The reason this is a silent-failure story and not a loud one is that GraphQL errors on unknown types usually manifest as empty result sets plus a "errors": [...] array in the response body. Plenty of client libraries treat empty results as a valid zero-length response and log the error array at debug level. Your code reads data.app.privateMetafields.edges, gets [], and moves on. The merchant's configuration just looks like it was never set.

accountNumber and routingNumber, Also Gone

A smaller but spicier one, buried in the same release:

Removed accountNumber and routingNumber fields from ShopifyPaymentsBankAccount.

If your app was reading bank account details from Shopify Payments — for displaying masked account info, for reconciling payouts against external bookkeeping, for compliance paperwork — those two fields no longer exist. The field resolver returns null. Whatever UI or report depended on them now shows blanks.

The reason Shopify gave is reasonable (PCI / financial-data exposure narrowing). The reason apps break anyway is that nothing in the upgrade path forces you to notice. You bump your API version header from 2024-10 to 2025-01, you ship, and the fields that used to come back populated just come back null. Everything else is identical.

Why CI Tests and Type Systems Don't Catch This

Every time I write up one of these stories — the GitHub PushEvent commits field, Stripe's Basil current_period_end move, now Shopify 2025-01 — the pattern is the same:

The upstream API version is under the upstream's control, not yours.
The breaking change is a field removal or a type reshape, not a new 4xx status.
Responses still parse. HTTP still returns success.
Your unit tests pass because you mocked the response shape yourself.
Your integration tests pass because your sandbox data was seeded before the change.
Your type checker passes because your types were generated against the old schema.
The break shows up in production, against real data, after a deploy that looked clean.

There is no test you can write inside your codebase that catches a response-shape change introduced by code you don't own. The contract is between two systems and you only control one of them.

What Actually Catches It

Three things can catch a silent upstream schema change, in order of cost:

1. Version pinning with forced upgrade cadence. Shopify lets you pin your API version via the Shopify-Api-Version header. Pin an explicit version and don't let it float. Then schedule the upgrade (2024-10 → 2025-01, etc.) as a deliberate project with a review of the full release notes, a grep of your codebase for removed/renamed fields, and a regression test against a non-production shop. This is what every Shopify app developer should already be doing. Most aren't, which is why forum posts like "Submit for review button is disabled after upgrading to 2025-04" keep showing up.

2. Deprecation-warning monitoring. Shopify exposes deprecated API call counts in the Partner Dashboard and will block app submissions if you have any in the 3-day window before review. Read the warnings, fix the calls. This requires that you bothered to upgrade in the first place, though — it doesn't catch drift on a version you've been sitting on.

3. Runtime shape monitoring. Poll the endpoints your app actually hits on a schedule, record the response shape, and alert when a field disappears, a type shifts, or nullability changes. This is the one catch for APIs that change shape out from under you without you bumping any versions — and it's the one that works for every third-party API, not just the ones that publish a deprecation dashboard. (FlareCanary does this; so do a few others. The point is to have something doing it, not specifically us.)

The economics matter. The cost of an undetected Shopify field rename isn't "an exception in the logs." It's usually something worse — wrong data on a merchant-facing dashboard, a fulfillment routing rule that silently misfires, a compliance report with a missing column. The business cost of one of those is larger than the annual cost of any monitor. And it only takes one.

The Next Shopify Release Is Already Doing This Again

Shopify's 2026-07 release (still months away as of this writing) is dropping grams from DraftOrderLineItem in favor of weight. customerPaymentMethodRemoteCreditCardCreate is fully removed after January 2026. These are the ones listed in the changelog; history says there will be 5–10 more smaller ones by the time the version actually ships.

If you integrate with Shopify, now is a good time to:

Grep your codebase for heldBy (without the App), privateMetafield, accountNumber, routingNumber, grams, multiLocation, customerPaymentMethodRemoteCreditCardCreate, metafieldDelete, visibleToStorefrontApi. Anything that comes back is a candidate break.
Pin your Shopify-Api-Version header explicitly if you aren't already.
Subscribe to the Shopify changelog and actually read it.
Set up shape monitoring on your most critical queries — fulfillment, orders, metafields, payments. Whether you do it yourself, use an observability tool, or use a schema-drift monitor, the cost of not doing it compounds every quarter.

Upstream API breaking changes are not a problem you can solve once. They're a recurring cost of running a product that depends on APIs you don't own. The apps that survive long-term aren't the ones that never get hit — they're the ones that notice within minutes instead of weeks.

I'm Wilson — I write about how third-party API schemas break, quietly, against apps that depend on them. If you integrate with Shopify, Stripe, GitHub, Twilio, or any of a dozen others, FlareCanary polls your critical endpoints and alerts on shape changes before your customers notice. Free tier. No card required.

Notion's 2026-04-01 API changed pagination cursors and the RateLimit-Reset format — here's what silently breaks

FlareCanary — Fri, 29 May 2026 05:00:43 +0000

Notion's 2026-04-01 API version shipped two changes that don't look dangerous in a release note and are very dangerous in a long-running integration:

Pagination cursors became opaque base64 strings.
The rate-limit reset value changed from a Unix timestamp to a delta in seconds.

Neither produces a schema error. Neither shows up in a diff of your request/response types. Both break code that was correct yesterday, and both fail in the direction that's hardest to notice: silent state corruption and silent loss of backoff.

Change 1: pagination cursors are now opaque base64

Historically, Notion start_cursor values were UUIDs. As of 2026-04-01 they're opaque base64-encoded strings. The compatibility rule is asymmetric, and the asymmetry is the trap:

Old-format cursors (UUIDs) still work on 2026-04-01. Forward compatibility is fine.
New-format (base64) cursors do not work on older API versions. A cursor minted by a 2026-04-01 caller is rejected (400 validation_error) if it's replayed against, say, 2025-09-03.

If you paginate in a single request loop on one pinned version, you'll never notice — you mint and consume the cursor in the same context. The failure shows up when a cursor outlives the request that created it:

Checkpointed / resumable syncs. A long workspace export persists next_cursor to a database or queue so it can resume after a crash or across a job boundary. The job that wrote the cursor was on 2026-04-01; the worker that resumes is still pinned to an older version (different service, different deploy cadence). The resume call 400s. Depending on how your retry logic treats a 400, you either hard-fail the sync or — worse — treat "invalid cursor" as "end of results" and silently truncate the export.
Mixed-version fleets. Ingestion service A is upgraded to 2026-04-01; reconciliation worker B still pins the old version. They share a cursor store. Every cursor A writes is poison to B. Nothing logs a version mismatch — it's just a 400 that looks like a transient Notion error.
Cursor caches keyed by query. Some integrations cache "where did I leave off for this database" by query hash. After the partial upgrade, cached cursors are a coin flip on whether they parse.

The reason this is easy to miss in review: the code that reads the cursor is unchanged and correct. The bug is the combination of a persisted cursor and a version skew between writer and reader. There's no single line you can point at.

Mitigations:

Do not upgrade your Notion-Version header mid-sync if you persist cursors. Drain in-flight syncs on the old version first, or reset sync state entirely on cutover.
Treat cursors as version-scoped. If you persist a cursor, persist the Notion-Version that minted it next to it, and refuse to replay a cursor under a different version — fail loudly with a clear message instead of letting Notion return an ambiguous 400.
On a forced cursor invalidation, restart that pagination from the beginning. Make sure your code distinguishes "invalid cursor, restart" from "no more pages, done." Conflating the two silently truncates data.

Change 2: RateLimit-Reset is now a seconds delta, not a Unix timestamp

Before 2026-04-01, the reset value Notion returned was a Unix timestamp — the wall-clock time the token bucket refills. As of 2026-04-01 it's a delta in seconds — how many seconds from now until refill.

Almost every backoff helper written against the old behavior looks like this:

reset = int(resp.headers["x-ratelimit-reset"])
sleep_for = reset - time.time()      # was: timestamp - now = seconds to wait
if sleep_for > 0:
    time.sleep(sleep_for)

Run that against the new format, where reset is now 30 (meaning "30 seconds"):

sleep_for = 30 - 1_775_000_000   ≈  -1.77e9

sleep_for is hugely negative. The if sleep_for > 0 guard fails, the sleep is skipped entirely, and the client immediately retries the request that was just rate-limited. You haven't slowed down — you've removed all backoff at the exact moment Notion told you to back off. The result is a retry storm that escalates you from soft 429s into longer enforced cooldowns or integration-level throttling.

The mirror-image bug is just as quiet: code that interprets the new small number as an absolute timestamp computes a "reset" in 1970 and concludes the bucket is already available — same effect, no wait.

There is no exception, no log line, no failed assertion. Throughput even looks better for a few minutes because you stopped sleeping. Then Notion clamps down and the integration's latency falls off a cliff with no obvious cause, because the cause was a header value that changed type, not shape.

Mitigations:

Treat the reset value as a duration, not a timestamp: sleep_for = float(resp.headers["x-ratelimit-reset"]), clamped to a sane max, and honor Retry-After when present.
Add an upper bound and a lower bound to any computed sleep. A correct backoff should never compute a negative wait or a multi-year wait; if it does, that's a format-mismatch signal — alert on it instead of clamping silently.
If you can, pin and assert: log the raw header on the first rate-limited response after a version bump and eyeball whether it's ~10^9 (timestamp) or ~10^1–10^2 (delta).

Why these two belong in the same checklist

Both changes share a signature we see constantly on review: the response is structurally identical, but a value's encoding or meaning changed. Your types still compile. Your mocks still pass — a mock returns whatever cursor or reset value you hard-coded, so the test never sees the new format. Your happy-path manual test passes, because it runs on one version in one process and never persists a cursor or hits a 429.

The breakage only appears with real state and real load: a cursor that crosses a version boundary, or a rate-limit response under contention. That's production, not CI.

Migration checklist

Audit every place a Notion cursor is persisted (DB, queue, cache, checkpoint file). For each, store the minting Notion-Version alongside it and reject cross-version replay explicitly.
Upgrade all services that share a cursor store in the same change, or don't share the store across versions. A partial fleet upgrade is the failure mode.
Ensure your pagination loop distinguishes "invalid/expired cursor → restart" from "no next_cursor → done." Never let a 400 silently end a sync.
Change rate-limit backoff to treat the reset value as a seconds delta. Add min/max bounds and alert (don't clamp) when a computed sleep is negative or absurdly large.
Add an integration test that exercises a real (small) paginated query and a forced 429 against the live API on 2026-04-01 — not a mock — before you flip the version in production.

Both of these are date-versioned, so nothing breaks until you bump Notion-Version. That's also the trap: the bump is a one-line change that passes review, passes CI, and detonates later in a resume path or under load, far from the diff that caused it.

FlareCanary watches your third-party APIs and SDKs for breaking changes like these — including value-encoding changes that keep the schema identical while silently corrupting state — and surfaces them before they hit production. Free tier monitors 5 endpoints.

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

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

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

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

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

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

Here is the silent-fail surface we keep seeing.

1. A clean 200 with the discount missing

The app queries discounts on its pinned version:

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

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

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

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

This is the dangerous one.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The fix

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Bedrock and Vertex AI run their own schedule

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

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

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

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

4. Mocked SDK tests will not catch this

A common test pattern:

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

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

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

5. Model-router fallback configs go silent

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

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

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

Audit your router configs alongside your direct call sites.

6. Evals and comparison harnesses lose their baseline

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

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

The fix

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

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

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

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

A clean migration checklist

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Cost-attribution dashboards now lie

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

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

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

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

5. Fallback chains lost their cheap degraded mode

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

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

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

6. Pinned eval baselines now track a moving target

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

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

What to actually do

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

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

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

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

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

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

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

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

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

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

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

The Timeline

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

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

What Actually Changes

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

Legacy response:

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

New response:

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

The shape change cascades:

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

2. `response_mime_type` → polymorphic `response_format`

Legacy request for JSON output:

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

New request:

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

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

3. `image_config` moves out of `generation_config`

Legacy:

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

New:

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

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

4. Streaming SSE event names rename

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

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

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

Legacy tool-call response:

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

New:

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

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

6. The `thought` step shape changes too

Legacy thought was minimal:

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

New thought carries a structured summary:

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

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

The Silent Surfaces

Walking through the six places this fails quietly:

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

How To Detect It Before May 26

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

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

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

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

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

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

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

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

Why This Is Worth Paying Attention To

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

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

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

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

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

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

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

What Actually Changed

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

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

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

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

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

Why This Is a Silent Failure, Not a Loud One

Walk through what each layer of a typical integration sees:

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

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

Who's Exposed

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

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

How To Detect It

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

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

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

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

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

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

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

  return rows;
}

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

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

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

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

The Pattern

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

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

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

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

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

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

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

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

What Actually Changes

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

Today:

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

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

After May 26:

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

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

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

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

The Four Quiet Surfaces

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

The classic shape is:

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

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

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

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

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

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

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

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

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

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

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

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

Surface 4: Observability and metrics start undercounting successful exchanges.

Three patterns to grep for in your monitoring code:

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

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

Who Should Audit Right Now

Three groups, ranked by likely impact:

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

The Migration Is Trivial; The Audit Is the Work

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

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

Or, in Python:

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

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

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

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

Once the production code is fixed, sweep:

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

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

The Pattern, Beyond Supabase

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

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

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

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

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

DEV Community: FlareCanary

Shopify Scripts stop executing June 30 — and the failure is silent: checkout completes at full price, no error

1. The cutoff itself fails silent — checkout just stops applying your rules

2. A deployed Function does nothing until a discount node exists in the Admin

3. The input query: a field you forget to request comes back null

4. combinesWith and discount strategy: a Script that always applied may now lose

What to actually do

Google retires every Imagen model on June 24 — and the Gemini image migration fails silently in 4 places

1. The endpoint and response shape changed — and a half-migrated parser fails quiet

2. sampleCount is gone — your batch silently collapses to one image per call

3. Aspect ratio moved namespaces — and became a suggestion

4. personGeneration has no clean equivalent — your safety posture shifts without a diff

5. The two things to also budget for

What to actually do

Atlassian Admin v1 APIs Go Dark on June 30 — Your User-Provisioning Script Probably Hits Eleven of Them

The eleven endpoints to grep for

What v2 actually looks like

OAuth scopes — one easy miss

What the failures will look like

The use cases that quietly break

What to do this quarter

Auth0 removes enabled_clients from connection reads July 13 — Terraform/Pulumi will silently see every client as disabled

The Two Silent Failure Modes

Mode 1: Drift-detection wipe

Mode 2: Multi-tenant provisioning over-restriction

What Actually Changed

Why It Slips Through Normal Detection

How To Detect It Now

The Pattern

Shopify Changed heldBy From a String to an Object in 2025-01 — Your Query Still Returns 200 OK

The heldBy → heldByApp Change

PrivateMetafield Is Just Gone

accountNumber and routingNumber, Also Gone

Why CI Tests and Type Systems Don't Catch This

What Actually Catches It

The Next Shopify Release Is Already Doing This Again

Notion's 2026-04-01 API changed pagination cursors and the RateLimit-Reset format — here's what silently breaks

Change 1: pagination cursors are now opaque base64

Change 2: RateLimit-Reset is now a seconds delta, not a Unix timestamp

Why these two belong in the same checklist

Migration checklist

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

1. A clean 200 with the discount missing

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

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

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

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

The fix

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

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

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

3. Bedrock and Vertex AI run their own schedule

4. Mocked SDK tests will not catch this

5. Model-router fallback configs go silent

6. Evals and comparison harnesses lose their baseline

The fix

A clean migration checklist

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

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

2. The reasoning slugs are now answering at low effort

3. Cost-attribution dashboards now lie

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

5. Fallback chains lost their cheap degraded mode

6. Pinned eval baselines now track a moving target

What to actually do

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

The Timeline

What Actually Changes

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

2. response_mime_type → polymorphic response_format

3. image_config moves out of generation_config

4. Streaming SSE event names rename

5. Function calls live in steps, not outputs

6. The thought step shape changes too

The Silent Surfaces

How To Detect It Before May 26

Why This Is Worth Paying Attention To

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

What Actually Changed

Why This Is a Silent Failure, Not a Loud One

3. The input query: a field you forget to request comes back `null`

4. `combinesWith` and discount strategy: a Script that always applied may now lose

2. `sampleCount` is gone — your batch silently collapses to one image per call

4. `personGeneration` has no clean equivalent — your safety posture shifts without a diff

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

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

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

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

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

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

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

2. `response_mime_type` → polymorphic `response_format`

3. `image_config` moves out of `generation_config`

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

6. The `thought` step shape changes too