CI runs cargo make carbide-lints, which is bare cargo carbide-lints with no flags, so the custom lints only see the default targets. The local pre-PR procedure runs carbide-lints --all-targets --all-features, and that difference is currently hiding a real finding.
Running the local form against a clean main reports two errors, both in the same file:
error: A sqlx::Transaction is being held across this 'await' point
--> crates/api-core/tests/integration/dns_resolution.rs:221:14
note: Transaction declared here
--> crates/api-core/tests/integration/dns_resolution.rs:172:13
That file moved into the integration suite in #5276. lint-police is green on recent PRs because the flagless invocation never reaches tests/integration, so nothing caught it on the way in.
What this involves
- Decide whether
txn_held_across_await is right about this test, then either restructure it so the transaction isn't held across the await or record why holding it is correct here.
- Match the CI invocation to the traversal we expect from the gate, so a target that is not linted today cannot pass unnoticed tomorrow.
- Expect the wider traversal to surface further findings that have accumulated out of view. Triage those before the stricter gate turns on, or the first run lands on an unrelated PR.
CI runs
cargo make carbide-lints, which is barecargo carbide-lintswith no flags, so the custom lints only see the default targets. The local pre-PR procedure runscarbide-lints --all-targets --all-features, and that difference is currently hiding a real finding.Running the local form against a clean
mainreports two errors, both in the same file:That file moved into the integration suite in #5276.
lint-policeis green on recent PRs because the flagless invocation never reachestests/integration, so nothing caught it on the way in.What this involves
txn_held_across_awaitis right about this test, then either restructure it so the transaction isn't held across the await or record why holding it is correct here.