Skip to main content

LINT.SUPPRESSION_DEPRECATED_RULE — a suppression names a rule on its way out

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

An entry in sqlens.ignore, or an #[SqlensIgnore] on a migration, names a rule that still exists and has been deprecated. The suppression works today and will quietly stop mattering.

Never an error, and that is governance rather than leniency​

Rules here are deprecated and never deleted. A configuration naming one is therefore still correct — it points at a check that is on its way out, not at a check that never existed. Refusing a run over it would make a correct configuration fail for the crime of having been written earlier.

The unknown-id case is the one that refuses, and it is a different mistake: there the entry names nothing at all and suppresses nothing.

What this says that nothing else does​

The audit suite reports every deprecated rule it withheld, and names the successor. What it cannot tell you is which line of your configuration named it — and that line is the thing somebody has to edit.

It also reaches a suite the other message does not. Nothing in a lint run said anything about deprecation before this notice existed, and lint is the suite that fires on every migration.

What to do about it​

The message names the successor when there is one:

  • A successor exists — point the suppression at it. The old id keeps working until the rule is finally removed, so there is no rush and no breakage either way.
  • No successor — the check is going away with nothing taking its place. Decide whether the finding it accepted still needs accepting; often the answer is that the concern moved somewhere else entirely.

What it does not cover​

A baseline entry naming a deprecated rule. Its references are built inside the baseline's own reader, and reaching them is a change to that seam rather than to this one. It is worth the same notice and is tracked separately.

Not a rule, and it says so​

This is a runner notice: no rule produced it, and none could, because it describes the project's configuration rather than a statement. It carries an id, a message prefix and this documentation URL exactly like a rule's finding, because a reader should not have to know the difference to act on it.

Sources​

  • RuleIdValidator, which computes the notice and has done since it was written.
  • The governance rule that rules are deprecated and never deleted, which is what makes this a notice rather than a refusal.