[
https://issues.apache.org/jira/browse/CAMEL-26408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-26408.
---------------------------------
Resolution: Fixed
Merged in https://github.com/apache/camel/pull/28703 (commit 411e25ec05f7) for
4.24.0.
_Claude Code on behalf of davsclaus_
> camel-openfga - batchCheck applies the single-request await timeout to the
> whole fan-out
> ----------------------------------------------------------------------------------------
>
> Key: CAMEL-26408
> URL: https://issues.apache.org/jira/browse/CAMEL-26408
> Project: Camel
> Issue Type: Bug
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Minor
> Fix For: 4.24.0
>
>
> Found during a camel-openfga quality review (reading {{main}} on
> 4.24.0-SNAPSHOT).
> h4. What happens
> {{OpenFgaAuthorizer.awaitTimeout()}}
> (components/camel-openfga/src/main/java/org/apache/camel/component/openfga/OpenFgaAuthorizer.java,
> lines 163-167) computes the per-exchange wait bound as {{(connectTimeout +
> readTimeout) * (maxRetries + 1) + AWAIT_SAFETY_MARGIN_MILLIS}} — about 85s
> with the 10000 / 10000 / 3 defaults. That is the right bound for a single
> {{check()}}: one connect + one request per attempt, across the first attempt
> and every retry, plus a margin.
> {{OpenFgaProducer.batchCheck()}} (OpenFgaProducer.java, lines 192-194) hands
> that same {{awaitTimeoutMillis}} to {{authorizer.await(() ->
> client.clientBatchCheck(requests, options))}}. {{clientBatchCheck}} issues
> one check request per object with at most {{maxParallelRequests}} (default
> 10) in flight, i.e. {{ceil(n / maxParallelRequests)}} serialized waves for n
> objects. The whole batch is one future, so {{await}}'s
> {{future.get(awaitTimeoutMillis)}} bounds the *entire* fan-out by a budget
> sized for a *single* request.
> h4. Impact
> Under high per-check latency (a slow or degraded OpenFGA server) and a large
> body, the batch's wall-clock can exceed the single-request bound; the
> Camel-level {{future.get}} then cancels an in-progress batch and the exchange
> fails with a misleading {{"Timed out after 85000ms ..."}}. It fails *closed*
> ({{batchCheck}} has no {{failOpen}} — returning the objects it never managed
> to filter would be the leak the filtering prevents), so this is a robustness
> / diagnostics bug, not a security issue. The default timeouts make it latent:
> it only bites when individual checks are slow and the batch is large.
> h4. Proposed fix
> Scale the await bound for the batch path by the number of waves — multiply by
> {{ceil(requests.size() / maxParallelRequests)}} when awaiting a
> {{clientBatchCheck}} — so the batch is given the budget its fan-out actually
> needs. At minimum, document that {{batchCheck}}'s effective bound is the
> single-request bound regardless of size, and make the timeout message name
> the knob to raise. Include a unit test (a mocked client whose future
> completes after the single-request bound but within the scaled bound).
> Related but distinct: CAMEL-26197 (other {{batchCheck}} bugs in the same
> method).
> _Claude Code on behalf of oscerd_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
