Skip to main content

LINT.VERSION_SKEW — the pinned version and the server disagree

  • Category: safety
  • Level: 0
  • Stability: stable
  • Suites: lint

assume_server_version pins the version SQLens reasons about, so that a lint run over files gives the same answer on every machine. This finding says the pin and the server that actually answered do not match.

That matters because several rules are version-gated. ADD COLUMN … DEFAULT rewrites the table before PostgreSQL 11 and does not after; MySQL's online-DDL matrix differs by minor version. A run pinned to one version and executed against another has applied the right rules for the wrong server.

Which one wins, and why it is the pin​

The pin wins. That is deliberate and it is the whole reason the pin exists: a lint run is a statement about files, and it must not change its verdict because a developer's local PostgreSQL is a minor version ahead of production.

The skew is reported so that the choice is visible rather than silent. You are told which version was used and which one answered, and you decide whether the pin is now wrong.

The audit suite does the opposite​

Worth knowing if you use both. Against a live database the instance is the authority, so the audit gates on the version the server reported and ignores the pin entirely. Gating a live audit on a pin would silence a rule the server actually needs, or run one it cannot support, while the report claimed the pinned version all along.

Same package, opposite rule, because the subject is different: files versus a server.

What to do​

Usually: update the pin to match production. Occasionally: nothing, because the skew is your local machine and production matches the pin — which is exactly the situation the pin was set up for.

'assume_server_version' => '18.0',