MQTT: Throw Runtime Exception when manual ack fails

[nkokitkar]

Description

Small fix to throw an exception when manual ack failed instead of a warning log.

Target

• I checked that the commit is targeting the correct branch (Camel 4 uses the main branch)

Tracking

• If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

• I checked that each commit in the pull request has a meaningful subject line and body.

• I have run mvn clean install -DskipTests locally from root folder and I have committed all auto-generated changes.

[gnodet]

Review — Claude Code on behalf of Guillaume Nodet

Verdict: REQUEST CHANGES (recommend closing)

This PR has a fundamental design flaw that makes the change ineffective.

CRITICAL: RuntimeException is silently swallowed

The onComplete() callback is invoked by UnitOfWorkHelper.doneSynchronization(), which catches all exceptions:

// UnitOfWorkHelper.java
try {
    synchronization.onComplete(exchange);
} catch (Exception e) {
    // logged and swallowed
}

This means the RuntimeException("Exchange was not acknowledged") thrown by this PR is silently caught and discarded. The MQTT message is still NOT acknowledged (same behavior as before the change), but now there's a misleading exception in the logs with no actionable outcome.

The change provides zero functional benefit.

Other issues

1. No tests — No unit or integration tests demonstrate or verify the intended behavior.
2. No JIRA issue — A behavioral change in message acknowledgement should have a tracking issue.
3. No documentation — No docs explaining when ACKNOWLEDGE_ALLOWED would be false or what the expected behavior should be.

Suggested alternative approaches

If the goal is to signal that acknowledgement was denied:

• Log a warning directly (simplest — don't throw, just log)
• Set the exchange as failed (exchange.setException(...)) before the synchronization callback
• Use the onFailure() path instead of onComplete()
• Use a custom error handler to handle the denial

The current approach of throwing from onComplete() is architecturally incompatible with how Camel processes synchronization callbacks.

[oscerd]

If we change the behavior this require a JIRA isssue.

[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 build-all, build-dependents, 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.

[Croway]

why debug instead of error?

[nkokitkar]

Reverted