Repo-history example

Supabase functions deploy: one orphan-prune change the repo's own checks missed.

In a measured replay of eight real Supabase CLI commits from repo history, the same functions deploy checks passed in standard CI every time. DriftFence kept flagging the same orphan-prune change across the full replay window.

With approved functions deploy behavior fixed in Git, DriftFence would have kept surfacing that prune change while the repo's own checks still passed.

See the first flagged change Back to results summary

First divergence

Functions deploy started pruning orphaned remote functions.

The first commit in this window already failed the DriftFence check. Supabase added orphan pruning to functions deploy --prune, while the same functions deploy checks still passed in standard CI and two nearby controls did not trigger DriftFence.

Blocked case

`--prune` started deleting remote functions.

Supabase added a prune step after deploy. The approved baseline deleted no remote functions, but later commits deleted two orphaned functions when --prune was enabled.

DriftFence report

Scenario

supabase.functions.deploy.prune-orphaned

Expected

output.deletedCount = 0

Observed

output.deletedCount = 2

Classification

violating

The supabase.functions.deploy.prune-no-orphans and supabase.functions.deploy.invalid-slug controls did not trigger DriftFence on the same commits. The flagged change stayed on one functions-deploy surface.

Across the replay window

One recurring prune change across the whole window.

This window does not have a before-and-after turn like Firebase or Serverless. The first commit already triggered the DriftFence check. What matters is that the same prune change kept showing up while the same functions deploy checks stayed green and two nearby deploy controls did not trigger DriftFence.

Same blocked case later

Same prune change on every commit

Every commit in the window showed the same orphan-prune change.
The same functions deploy checks still passed in standard CI.
No command failure interrupted the replay.

Nearby workflows with no DriftFence signal

Two other deploy controls did not trigger DriftFence

The no-orphans control kept output.deletedCount at 0.
Invalid function slugs kept the expected validation error before deploy work.
Both neighboring deploy controls produced no DriftFence signal throughout.

Scope of the change

One functions-deploy behavior changed

This result is about one prune behavior inside functions deploy.
That behavior changed while the same deploy checks stayed green.
Two nearby controls did not show the same change.

Method

How it was measured.

This replay fixes one Supabase functions-deploy baseline, reruns the same deploy checks on each commit, and counts the recurring prune signal once even though it persisted across the full window. Exact commit references are linked below.

Replay size: 8 commits
Fixed workflows: functions deploy --prune, prune-no-orphans, and invalid-slug validation
The same functions deploy checks reran on every commit in the window
DriftFence reran on every commit with the same approved baseline
This page counts the recurring prune change once, even though it persisted across all eight commits

Source material

Method and source files.

The links below show the benchmark notes and pinned replay plan for this Supabase example.

Measurement notes

The benchmark results log records the completed Supabase window, including the replay size, outcome mix, and representative first flagged change.

Benchmark results

Fixed test plan

The Supabase replay definition fixes the three functions deploy workflows and the replay window used here.

See the product, results, pricing, and trust pages alongside this Supabase example.