Changed default

Advisory
Something changed for the previous application version, but the evidence is not sufficient to call it a compatibility regression.

New orders default to "pending" instead of "new". The schema still accepts v1, but v1 now sees different data.

Recorded example: genuine engine output generated Sat, 24 Oct 2026 18:29:57 GMT from the committed fixture. Run it again live below.

Baseline schema
Proposed schema
Previous versionshop-v1
2/2 test files passno database errors
1/2 test files passno database errors, identical in all 2 runs
Current versionC-assertion-drift
Not needed: ordinary CI covers this
Not configured

The outlined cell is the compatibility question. The verdict comes only from it, compared against the cell to its left.

Why

  1. test/orders.test.js: assertion drift

Next step

Review the listed findings and decide whether the old version's changed behaviour is acceptable during rollout.

Starts a throwaway PostgreSQL and runs the full experiment, usually in under 15 seconds.

Evidence

Assertion drift test/orders.test.js

Observed
test/orders.test.js passes on the baseline schema and fails in all candidate runs without any new database error.
Test output (tail): error: |- | Expected values to be strictly equal: | code: 'ERR_ASSERTION' | name: 'AssertionError'
Interpretation
Likely a changed value or behaviour rather than a schema incompatibility (behavioural changes in this migration: Column orders.status default 'new'::text → 'pending'::text). A human should decide whether the old application's expectation still matters while both versions run.
Linked change
column_default_changed:orders.status

Schema changes

1 of 1 risk-bearing schema change(s) were exercised by the old application's tests in the control run.

ChangeRisk to old statementsExercised by previous version
Column orders.status default 'new'::text → 'pending'::text
Inserts that omit this column will store a different value.		behavioralYes, 2 statements in test/orders.test.js

Runs

Proposed migration: 002_status_default.sql · PostgreSQL 16.15 (Debian 16.15-1.pgdg12+2) · gate does not block (exit 0)

RunMigrationsTest filesDatabase errorsStatements logged
control (old app × baseline schema)1/12/2 pass07
candidate #1 (old app × proposed schema)2/21/2 pass04
candidate #2 (old app × proposed schema)2/21/2 pass04

Download this report: JSONMarkdownJUnit XML

What this result does not cover
  • Current application × proposed schema (no current app configured).
  • Performance / lock-time analysis (out of scope).
  • Skewcheck only observes code paths that the old application's tests execute; untested paths are reported as coverage gaps, not as safe.
  • Coverage is identifier-level: a statement "touches" a changed object when it names the table (and column, or uses *). It is not a SQL parser.
  • Correlation between an error and a schema change uses a fixed set of deterministic rules (R1–R6). Anything else is reported as ADVISORY, never UNSAFE.
  • Performance, locking and migration runtime on production-sized data are not evaluated.
  • Test files of one run share a database and run sequentially; ordering effects are identical across runs but are not isolated.
  • Data-only migration effects are detected only when a test asserts on the affected data.