camel-salesforce: Improve error resilience in subscription failure handling

[shaipan]

Improve error handling in SubscriptionHelper to recover from more transient Salesforce
Streaming API failures instead of aborting the subscription.

• Treat IOException, TransportException, and TimeoutException as retryable temporary errors
• Retry with backoff on authentication (401), authorization (403), security policy denial,
  org daily event limit, and missing error message failures
• Handle invalid channel errors (400) by removing the channel from the subscription list
  instead of retrying indefinitely

[davsclaus]

@jeremyross just in case you have a bit time to quickly take a look

[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-salesforce/camel-salesforce-component

All tested modules (10 modules)

• Camel :: JBang :: MCP
• Camel :: JBang :: Plugin :: Route Parser
• Camel :: JBang :: Plugin :: TUI
• Camel :: JBang :: Plugin :: Validate
• Camel :: Launcher :: Container
• Camel :: Salesforce
• Camel :: Salesforce :: CodeGen
• Camel :: Salesforce :: Maven Plugin
• Camel :: YAML DSL :: Validator
• Camel :: YAML DSL :: Validator Maven Plugin

---

⚙️ View full build and test results

[gnodet]

Thanks for improving the error resilience in the Salesforce Streaming subscription handling, @shaipan! This addresses a real operational pain point. A few observations:

Missing tests: Per project standards, every PR should include tests for new behavior. The new error handling paths in subscriptionFailed() and the extended isTemporaryError() method are not covered by the existing SubscriptionHelperTest. Unit tests verifying that IOException, TransportException, and TimeoutException are treated as temporary, and that the various 401/403 error strings trigger retry, would strengthen confidence in these changes.

401/403 retry without token refresh: Treating AUTHENTICATION_INVALID (401) and authorization errors (403) as retryable is reasonable for transient failures. However, the retry path re-calls subscribe() without explicitly triggering a session token refresh. If the token is genuinely expired, all retries may fail identically, consuming the full backoff budget before aborting. Worth confirming that the CometD handshake/subscribe path handles token refresh internally.

Minor: Two comments explaining the non-obvious Tasks.foregroundTask() usage (using initialDelay as a sleep and maxIterations(1) to run once) were removed. The pattern isn't self-documenting — consider keeping them.

Claude Code on behalf of Guillaume Nodet

[shaipan]

Thanks for improving the error resilience in the Salesforce Streaming subscription handling, @shaipan! This addresses a real operational pain point. A few observations:

Missing tests: Per project standards, every PR should include tests for new behavior. The new error handling paths in subscriptionFailed() and the extended isTemporaryError() method are not covered by the existing SubscriptionHelperTest. Unit tests verifying that IOException, TransportException, and TimeoutException are treated as temporary, and that the various 401/403 error strings trigger retry, would strengthen confidence in these changes.

401/403 retry without token refresh: Treating AUTHENTICATION_INVALID (401) and authorization errors (403) as retryable is reasonable for transient failures. However, the retry path re-calls subscribe() without explicitly triggering a session token refresh. If the token is genuinely expired, all retries may fail identically, consuming the full backoff budget before aborting. Worth confirming that the CometD handshake/subscribe path handles token refresh internally.

Minor: Two comments explaining the non-obvious Tasks.foregroundTask() usage (using initialDelay as a sleep and maxIterations(1) to run once) were removed. The pattern isn't self-documenting — consider keeping them.

Claude Code on behalf of Guillaume Nodet

@gnodet The methods are private and the existing test pattern in the file doesn't cover listener callbacks.
Reverted the comments that were removed in earlier PR.

[davsclaus]

Thanks @shaipan

[shaipan]

Hi @gnodet @davsclaus are we good to commit this? Or any more chanegs needed from my side. I have 2 3 more bugs in this area to commit.

[davsclaus]

I created a ticket to capture your PRs in CAMEL-23391 as we need this for the release notes to track notice changes in this component