CAMEL-24243: camel-aws2-athena - do not relaunch a still-running query when waitTimeout expires

[oscerd]

Problem

Athena2Producer.startQueryExecution() drives two nested loops:

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:

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

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• components/camel-aws/camel-aws2-athena

---

🔬 Scalpel shadow comparison — Scalpel: 9 tested, 29 compile-only — current: 9 all tested

Maveniverse Scalpel detected 38 affected modules (current approach: 9).

⚠️ Modules only in Scalpel (29)

• apache-camel
• camel-allcomponents
• camel-catalog
• camel-catalog-console
• camel-catalog-lucene
• camel-catalog-maven
• camel-catalog-suggest
• camel-componentdsl
• camel-csimple-maven-plugin
• camel-endpointdsl
• camel-endpointdsl-support
• camel-itest
• camel-jbang-core
• camel-jbang-it
• camel-jbang-main
• camel-jbang-plugin-edit
• camel-jbang-plugin-generate
• camel-jbang-plugin-kubernetes
• camel-jbang-plugin-test
• camel-kamelet-main
• camel-launcher
• camel-report-maven-plugin
• camel-route-parser
• camel-yaml-dsl
• camel-yaml-dsl-deserializers
• camel-yaml-dsl-maven-plugin
• coverage
• docs
• dummy-component

Skip-tests mode would test 9 modules (1 direct + 8 downstream), skip tests for 29 (generated code, meta-modules)

Modules Scalpel would test (9)

• camel-aws2-athena
• camel-jbang-mcp
• camel-jbang-plugin-mcp
• camel-jbang-plugin-route-parser
• camel-jbang-plugin-tui
• camel-jbang-plugin-validate
• camel-launcher-container
• camel-yaml-dsl-validator
• camel-yaml-dsl-validator-maven-plugin

Modules with tests skipped (29)

• apache-camel
• camel-allcomponents
• camel-catalog
• camel-catalog-console
• camel-catalog-lucene
• camel-catalog-maven
• camel-catalog-suggest
• camel-componentdsl
• camel-csimple-maven-plugin
• camel-endpointdsl
• camel-endpointdsl-support
• camel-itest
• camel-jbang-core
• camel-jbang-it
• camel-jbang-main
• camel-jbang-plugin-edit
• camel-jbang-plugin-generate
• camel-jbang-plugin-kubernetes
• camel-jbang-plugin-test
• camel-kamelet-main
• camel-launcher
• camel-report-maven-plugin
• camel-route-parser
• camel-yaml-dsl
• camel-yaml-dsl-deserializers
• camel-yaml-dsl-maven-plugin
• coverage
• docs
• dummy-component

ℹ️ Shadow mode — Scalpel observes but does not affect test execution. Learn more

All tested modules (38 modules)

• Camel :: AWS2 Athena
• Camel :: All Components Sync point
• Camel :: Assembly
• Camel :: Catalog :: CSimple Maven Plugin (deprecated)
• Camel :: Catalog :: Camel Catalog
• Camel :: Catalog :: Camel Report Maven Plugin
• Camel :: Catalog :: Camel Route Parser
• Camel :: Catalog :: Console
• Camel :: Catalog :: Dummy Component
• Camel :: Catalog :: Lucene (deprecated)
• Camel :: Catalog :: Maven
• Camel :: Catalog :: Suggest
• Camel :: Component DSL
• Camel :: Coverage
• Camel :: Docs
• Camel :: Endpoint DSL
• Camel :: Endpoint DSL :: Support
• Camel :: Integration Tests
• Camel :: JBang :: Core
• Camel :: JBang :: Integration tests
• Camel :: JBang :: MCP
• Camel :: JBang :: Main
• Camel :: JBang :: Plugin :: Edit
• Camel :: JBang :: Plugin :: Generate
• Camel :: JBang :: Plugin :: Kubernetes
• Camel :: JBang :: Plugin :: MCP
• Camel :: JBang :: Plugin :: Route Parser
• Camel :: JBang :: Plugin :: TUI
• Camel :: JBang :: Plugin :: Testing
• Camel :: JBang :: Plugin :: Validate
• Camel :: Kamelet Main
• Camel :: Launcher
• Camel :: Launcher :: Container
• Camel :: YAML DSL
• Camel :: YAML DSL :: Deserializers
• Camel :: YAML DSL :: Maven Plugins
• Camel :: YAML DSL :: Validator
• Camel :: YAML DSL :: Validator Maven Plugin

---

⚙️ View full build and test results

[gnodet]

Correct fix for a real bug where a still-running Athena query was relaunched when waitTimeout expired, orphaning the previous execution. The isWaitTimeoutExceeded() guard in shouldAttempt() correctly closes the gap, and its interaction with isRetry ensures retryable failures still get another attempt.

The regression test aStillRunningQueryIsNotRelaunchedWhenTheWaitTimeoutExpires directly reproduces the bug scenario, and the retry-path test guards against over-suppression. CI passes on both JDK 17 and 25.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of Guillaume Nodet