oscerd opened a new pull request, #25040:
URL: https://github.com/apache/camel/pull/25040
## Problem
`Athena2Producer.startQueryExecution()` drives two nested loops:
```java
while (athena2QueryHelper.shouldAttempt()) {
queryExecutionId = doStartQueryExecution(athenaClient,
exchange).queryExecutionId();
athena2QueryHelper.markAttempt();
while (athena2QueryHelper.shouldWait()) {
athena2QueryHelper.doWait();
getQueryExecutionResponse = doGetQueryExecution(queryExecutionId,
athenaClient);
athena2QueryHelper.setStatusFrom(getQueryExecutionResponse);
}
}
```
The inner loop exits on **three** conditions: success, failure/retry, and
`waitTimeout` expiry. Only the first two set state on the helper —
`setStatusFrom()` assigns `isSuccess`/`isFailure`/`isRetry` only when the
query
has actually completed.
When the inner loop exits because `millisWaited >= waitTimeout` while the
query
is still `QUEUED`/`RUNNING`, none of those flags are set. `shouldAttempt()`
then
sees `attempts < maxAttempts`, no failure, no success, not interrupted — and
returns `true`. The outer loop calls `doStartQueryExecution` again,
**submitting
a brand-new Athena query while the previous one is still running.**
## Impact
With `maxAttempts > 1` (the documented way to retry failed queries):
- every `waitTimeout` expiry submits another execution of the same SQL;
- the earlier executions are orphaned — still running, still scanning data,
still billed;
- the `CamelAwsAthenaQueryExecutionId` header returned to the route belongs
to
the **last** submission, so the caller cannot correlate or cancel the
earlier ones;
- `clientRequestToken` is not auto-generated
(`Athena2Producer.determineClientRequestToken` reads only a header or the
endpoint option), so Athena does not deduplicate the submissions by
default.
This contradicts the documented contract in `aws2-athena-component.adoc`:
> Upon failure, the query would be automatically retried up to two more
times if
> the failure state indicates the query may succeed upon retry
Retry is documented as a response to **failure states**, not to a query
simply
taking longer than `waitTimeout`.
## Fix
Treat `waitTimeout` expiry as terminal for the attempt loop.
`shouldAttempt()`
now bails out when the wait window elapsed while the query was still running,
after success and failure have been ruled out:
```java
private boolean isWaitTimeoutExceeded() {
if (this.attempts == 0 || this.isRetry) {
return false;
}
return now() - this.startMs >= this.waitTimeout;
}
```
A completed-and-retryable failure still consumes another attempt, because
`setStatusFrom()` sets `isRetry` for it before `shouldAttempt()` runs — so
the
documented retry behaviour is preserved.
## Tests
- `aStillRunningQueryIsNotRelaunchedWhenTheWaitTimeoutExpires()` — query
stays
`RUNNING` past the wait window; asserts `shouldAttempt()` is `false` and
`attempts` stays at 1. Fails on `main` (`Expecting value to be false but
was
true`), passes with the fix.
- `aRetryableFailureStillConsumesAnotherAttemptAfterTheWaitTimeout()` — a
`GENERIC_INTERNAL_ERROR` with `retry=always` still yields
`shouldAttempt() == true`, guarding the retry path.
Full class 24/24 green. `assertj-core` added test-scoped for the new
assertions.
## Backport
The loop is identical on `main`, `camel-4.18.x` and `camel-4.14.x` →
targeted at
4.22.0, 4.18.4, 4.14.9.
---
_Claude Code on behalf of oscerd_
--
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]
