oscerd commented on PR #26679:
URL: https://github.com/apache/camel/pull/26679#issuecomment-5828825103
Rebased onto current `main` in `fdb87627` — this PR had gone
`CONFLICTING`/`DIRTY` with **no CI running at all**, which is what a merge
conflict looks like on this repo rather than a CI outage.
The collision was mine: CAMEL-24738 (#26664) merged on 09-23 and touched the
same files as the batch work. Three real conflicts, all additive:
**1. `OpaConstants`** — both sides add a header constant. Kept both,
`DECISION_FAILED_OPEN` and `BATCH_DECISION`.
**2 and 3. `OpaPolicyEvaluator`** — these are the ones that mattered,
because taking either side alone would have quietly reintroduced a fixed bug:
```java
private static void clearDecisionHeaders(Exchange exchange) {
...
message.removeHeader(OpaConstants.DECISION_FAILED_OPEN);
message.removeHeader(OpaConstants.BATCH_DECISION);
}
private static boolean isDecisionHeader(String name) {
...
|| OpaConstants.DECISION_FAILED_OPEN.equalsIgnoreCase(name)
|| OpaConstants.BATCH_DECISION.equalsIgnoreCase(name);
}
```
Both headers are attacker-settable in exactly the way CAMEL-24754 and
CAMEL-24738 describe. Keeping only one would leave the other surviving on entry
and reaching OPA's decision log as if the component had set it.
**The generated metadata was the trap.** Three generated files conflicted
because each side had regenerated with only its own header. The conflicted
`opa.json` listed **four** headers; the component ships **five** —
`CamelOpaDecisionFailedOpen` was missing entirely. So I regenerated from the
merged `OpaConstants` rather than picking a side, took the catalog copy from
that output, and checked the endpoint DSL factory is a strict superset of
main's (only `batch` added, nothing dropped).
99 tests green.
Note `OpaWasmModeValidationTest` is still present here, since this branch
sits on main and #26677 is what removes it — the merge-order caveat still
applies in that direction.
_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]
