oscerd commented on PR #26679: URL: https://github.com/apache/camel/pull/26679#issuecomment-5810051919
Both fixed in `c125527a`, and both were real — I checked each against the code rather than taking the wording as read. **Headers.** `setDecisionHeaders` writes three (`DECISION_ALLOW`, `DECISION`, `POLICY_PATH`); `setBatchDecisionHeaders` writes two (`BATCH_DECISION`, `POLICY_PATH`). So `CamelOpaDecision` is unset in batch mode as well, and naming only `CamelOpaDecisionAllow` did leave the reader to assume the rest survive. Now: > Neither `CamelOpaDecisionAllow` nor `CamelOpaDecision` is set in batch mode - there is no single verdict, and no single decision document - and both are cleared on entry like the other decision headers, so a value an inbound message supplied never survives. `CamelOpaPolicyPath` *is* set, to the same value a single evaluation records, so tooling can read it either way. **Total failure.** You are right that "denies every element" is the wrong shape. The path throws and `setBatchDecisionHeaders` is never reached, which is exactly what `failsClosedWhenTheWholeBatchCannotBeEvaluated` asserts — so someone reading that sentence would write code expecting a `List` of `false` and get an exception. Now: > A call that fails entirely - the server could not be reached at all - fails the exchange rather than denying each element: it carries no verdict at all, not a list of `false`. Under `failOpen` that same failure allows every element instead. I kept the `failOpen` half, which was accurate as you noted. Documentation only, and the catalog mirror is updated alongside the source so the "uncommitted changes" check stays quiet. _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]
