detekt and dokka fail the gate intermittently with nothing to fix

[rasros]

What

The gate fails intermittently inside detekt and dokka, with no finding to act on, and passes on an unchanged re-run. Both tools come from com.eignex.kmp on alpha analysis engines — detekt 2.0.0-alpha.6 on Java 22.

Three signatures seen in one session:

• :klause:detekt fails after reporting 0 findings, with No receiver found in qualified expression at KtQualifiedExpression.getReceiverExpression while analysing an untouched test file.
• :klause:detekt fails with @NotNull method com/intellij/openapi/application/AsyncExecutionService.getService must not return null.
• :klause:dokkaGeneratePublicationHtml fails in CI with Error in translating of symbol (hasWideFactor) in a file the change never touched, while lintDocs --rerun-tasks passes locally on the same tree.

Each reproduced as one red run followed by a clean one with no edit in between.

Why

A red gate with no finding reads exactly like a real violation, so the cost is a bug hunt against a file that is fine — and in CI it blocks a PR that is green. detekt { toolVersion = ... } does configure from this repo, so pinning is possible here; whether a different alpha is less flaky is unmeasured, which is why this is an issue rather than a patch.

.rules now records how to recognise the flake, so the immediate harm is contained.

[rasros]

Reopening: the No receiver found in qualified expression signature is not a flake, and the guidance this issue put in .rules — re-run it, a genuine violation names your file — sends you the wrong way for this one.

It is deterministic, and it names the right file. Every occurrence landed on a file whose import block detekt's own autoCorrect wants to rewrite:

run	crashed on	that file's state
ff7bf92 14:52	SmtLibMode.kt	com.eignex.klause.ir.ObjectiveSense sorted before com.eignex.klause.formats.smtlib.*
9848378 17:06	XcspMode.kt	...ir.ObjectiveSense sorted before ...formats.xcsp3.Xcsp3
PR #1695	XcspMode.kt	same

Both misorderings came in with 462350a, which moved ObjectiveSense into ir without resorting the imports at the call sites. Running :klause-cli:detektCommonMainSourceSet locally rewrites exactly those two files and no others.

The mechanism is autoCorrect mutating the file under the analysis: a formatting rule rewrites the import list mid-run, and a later rule consulting type information finds a qualified expression (ObjectiveSense.MAXIMIZE) whose receiver no longer resolves against the stale context. I hit the same class of failure from the other direction while a build was running — editing a source file under it produced Range [0, 27) out of bounds for length 4 on the file I had touched.

That also explains why it never reproduces locally the obvious way: run detekt on its own and it has no binding context, so the type-resolution rule never runs and the autocorrection lands harmlessly. It needs the full check graph to bite.

7b4d7d9 fixed both import orders in passing, so main should be clean right now. That is a trigger removed, not the bug — any future file needing an autocorrection can set it off again, which is why this stays open. Worth trying detekt { toolVersion = ... } on a newer alpha, per this issue's original note, or disabling autoCorrect on the CI path so analysis runs against a stable tree.

The AsyncExecutionService and dokka hasWideFactor signatures are untouched by this — the latter turned out to be real too, and was fixed by #1664.