Skip to main content

LINT.SERVER_BELOW_FLOOR — the version this run reasons from is below the supported floor

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

SQLens supports PostgreSQL 18 and above, and MySQL 8.4 and above. This finding says the version this run reasoned from — the server that answered, or the version you pinned — is older than that.

The run did not stop. You still get every finding, because a qualified report is worth more than no report at all. What you do not get is the assurance that those findings describe your server.

Why the report may be wrong in both directions​

This is the part worth reading twice, because the intuition is usually one-sided. "Old server, so the tool is being over-cautious" is only half of it:

  • A false alarm. A rule may flag behavior your server does not have. ADD COLUMN … DEFAULT rewrites the whole table before PostgreSQL 11 and does not after; a rule written for the newer behavior can describe a hazard that is not there on yours.
  • A missed finding — the dangerous half. A rule may stay silent about behavior your server does have. Rules are written against the supported floor, so a hazard that only exists on older versions has no rule at all. A clean report is not evidence that there is nothing to find; on an unsupported version it is evidence that nobody looked for the right things.

Which of the two happened cannot be determined from here, so both are stated. That is the reason this is an undetermined finding rather than a fail: nothing about your schema is wrong. What is uncertain is whether these verdicts apply to this server.

Where it shows up​

ReporterWhere
consolethe run header, the finding itself, and the undetermined-reason count in the summary
jsonrun.server_versions[].version (marked inline), findings[], and summary.counts.undetermined_reason
githubthe preamble ::notice and a ::warning annotation

The header marker rides in the version string itself, so it reaches every reporter without any of them having to know about this finding specifically.

A pinned version is judged the same way​

If assume_server_version is set, the pin is what gets judged — because the pin is what every finding in the report describes. Pinning an unsupported version to silence this finding does the opposite of what it looks like: it makes the whole report a statement about a version SQLens was never written for.

What to do​

Upgrade the server, or raise the pin to a supported version. Until then, treat the report as advisory rather than authoritative — particularly a clean one.

When it is not reported​

Four lint runs never carry this finding, although their headers still carry the marker: an unsupported engine, a strict-tool stop, an unresolvable pending set, and a --file run that could not be configured. Those runs produced no verdicts, and there is nothing to qualify. The header marker is the honest half — it says what the run's premises were, even when the run reached no conclusions.