oscerd opened a new pull request, #9072:
URL: https://github.com/apache/camel-quarkus/pull/9072
Fixes #9056.
`TransactionalJtaTransactionPolicy` is the base class of all six
`PROPAGATION_*` beans registered by `JtaProcessor`. Two sites logged a failure
and carried on:
```java
final protected void rollback(boolean isNew) throws Exception {
try {
if (isNew) { transactionManager.rollback(); } else {
transactionManager.setRollbackOnly(); }
} catch (Throwable e) {
LOG.warn("Could not rollback transaction!", e); // and likewise
for resume
}
}
```
In the participating case (`PROPAGATION_REQUIRED` / `MANDATORY` joining an
existing transaction) a failed `setRollbackOnly()` meant the outer transaction
was never marked, so a route that handled the exception could go on to commit.
A failed `resume()` meant subsequent work ran outside the transaction the
policy was expected to restore. Both were visible only as a log line.
**The care this needs is not to make it worse.** `rollback` is called from
two places that already have an exception on its way out, and
`resumeTransaction` is called from `finally` blocks in
`RequiresNewJtaTransactionPolicy` and `NotSupportedJtaTransactionPolicy` — a
naive rethrow would replace the original failure with the cleanup failure,
which is a worse outcome than the current logging.
So:
- `rollback` now raises a `CamelException`. `runWithTransaction` and
`commit` route it through a `rollbackSuppressing` helper that attaches it to
the in-flight exception via `addSuppressed`. The original exception still
propagates unchanged.
- `resumeTransaction(Transaction, Throwable)` takes the in-flight exception.
When there is one the resume failure is attached to it; when the body
succeeded, the resume failure is raised on its own. The two suspending policies
capture the exception and pass it in.
**No signatures change.** `resumeTransaction(Transaction)` keeps its exact
shape and wraps a failure in a `RuntimeCamelException`, so nothing outside the
repository stops compiling. If you would rather it simply declared `throws
Exception` and dropped the overload, that is a small change and I am happy to
make it — I kept compatibility because the issue did not settle that point.
**Tests**
`JtaTransactionFailurePropagationTest` covers the four cases, using the
existing `MockTransactionManagerProducer`:
| Case | Asserts |
|---|---|
| `setRollbackOnly()` fails while participating | original exception still
thrown, marking failure suppressed |
| `rollback()` fails | original exception still thrown, rollback failure
suppressed |
| `resume()` fails, body succeeded | resume failure surfaces |
| `resume()` fails, body threw | body's exception still thrown, resume
failure suppressed |
All four fail against the previous behaviour, each reporting `got []` —
nothing attached, which is the defect. The module is green at 18/18, with all
six existing policy test classes unaffected. `./mvnw clean install -DskipTests`
from the root passes with no regenerated artifacts left behind.
Migration guide entry added, since an application that handles exceptions
and continues may now learn about a failure it previously never saw.
> Note: this adds `docs/modules/ROOT/pages/migration-guide/3.40.0.adoc`, as
do #9066 and #9069. Whichever merge later need a trivial conflict resolution
there and in `migration-guide/index.adoc`.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
