templates: type the correlateMessageEvent catch in Abort and Wait, and the no-subscription miss behind it (#7230)

[delchev]

What

#7184 (#7145) typed the blanket catch (RuntimeException) in AbortOnDelete.java.template, but the two siblings that wrap Process.correlateMessageEvent kept swallowing everything:

• events/Abort.java.template — catch (RuntimeException notAborting) {}
• events/Wait.java.template — catch (RuntimeException notParked) {}

A correlation that fails because the engine/DB is down, the tenant scope is wrong, or the message name was mis-generated was indistinguishable from the expected "the instance is not parked here" — and a wait step that is never resumed is exactly the kind of incident an operator has to explain later with nothing in the log.

The platform half

Typing the catch needed a typed miss to catch. BpmProviderFlowable.correlateMessageEvent queried the execution carrying the message subscription and then called execution.getId() — so an instance that is running but not subscribed to the message surfaced as a NullPointerException, which no listener can honestly single out. It now throws the same IllegalArgumentException that validateProcessInstanceId raises for an instance that has already ended (or belongs to another tenant), naming both the instance and the message.

The template half

Both templates follow the AbortOnDelete recipe:

} catch (IllegalArgumentException notParked) {
    LOG.debug("... was not parked on \"...\" ...", instance, notParked);
} catch (RuntimeException failed) {
    LOG.warn("Could not resume ... - it stays parked", instance, failed);
}

The warn message names the consequence in each case: a flow still running over a record whose status says it is over (abort), an instance that stays parked forever (wait). Fail-soft, but never silent. The class javadocs say the same.

Verification

• IntentEngineIT — 77/77 green. Extended: the two catch shapes plus assertFalse that the old empty catch (RuntimeException notParked/notAborting) is gone.
• IntentEmissionCoverageIT — green. Same assertions on RfqFlowAwaitReplyWait and ApprovalFlowAbort. Both ITs compile the generated handlers, so the new catch order is checked by javac, not only by contains.
• components/engine/engine-bpm-flowable unit suite — 35/35 green.
• formatter:validate green on the changed modules with the formatter cache wiped.

Not run: the full reactor test suite, and no runtime test exercises a correlation against a live down-engine (there is no existing harness for it).

Sibling sweep

Grepped every *.template for the same shape: the remaining catch (RuntimeException e) blocks in Trigger.java.template, Repository.java.template and the three Entity*Controller templates all log the throwable already. correlateMessageEvent is called from exactly these two templates.

Fixes #7230

🤖 Generated with Claude Code