You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by "JiriOndrusek (via GitHub)" <gi...@apache.org> on 2026/09/15 13:25:59 UTC
[PR] CAMEL-24753: Add filter support to the langchain4j-ingest Kamelets [camel-kamelets]
JiriOndrusek opened a new pull request, #3033:
URL: https://github.com/apache/camel-kamelets/pull/3033
⚠️ Requires apache/camel#26471 ([CAMEL-24753](https://issues.apache.org/jira/browse/CAMEL-24753) , unmerged): the sink options bind to component options that PR introduces, and the Citrus tests fail without it — gating the merge the same way #3016 was gated on Camel 4.23.
Follow-up to #3016: exposes the filtering added to camel-langchain4j-ingest by [CAMEL-24753](https://issues.apache.org/jira/browse/CAMEL-24753) (apache/camel#26471).
- file-source: optional include/exclude Ant globs forwarded to the file consumer's antInclude/antExclude — a filtered file is never read.
- sink: passthrough of the component's includeId, excludeId, minDocumentSize and documentFilter options — rejected deliveries answer outcome=filtered and never keep a
dedup claim. The properties are optional {{?...}} parameters, so unset they are inert on any Camel; setting one needs Camel 4.23+.
Citrus tests cover both kamelets; like the #3016 suite they run with -Dcamel.version=4.23.0-SNAPSHOT.
_🤖 Generated with Claude Code (https://claude.com/claude-code)_
--
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: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] CAMEL-24753: Add filter support to the langchain4j-ingest Kamelets [camel-kamelets]
Posted by "JiriOndrusek (via GitHub)" <gi...@apache.org>.
JiriOndrusek commented on PR #3033:
URL: https://github.com/apache/camel-kamelets/pull/3033#issuecomment-5775760068
@oscerd I think i fixed the issue by https://github.com/apache/camel/pull/26706 (in Camel)
--
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: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] CAMEL-24753: Add filter support to the langchain4j-ingest Kamelets [camel-kamelets]
Posted by "oscerd (via GitHub)" <gi...@apache.org>.
oscerd commented on PR #3033:
URL: https://github.com/apache/camel-kamelets/pull/3033#issuecomment-5773264580
@JiriOndrusek the two failing tests are not caused by this PR. **They fail the same way on an unmodified `main`.**
I ran `OpenApiIT` on `main` at c23ad6dfd, with nothing from this branch:
```
✘ TEST FAILED: rest-openapi-sink-delete-pet-test
✘ TEST FAILED: rest-openapi-sink-add-pet-test
ValidationException: Values not equal for header element 'citrus_http_request_uri',
expected '/petstore/pet' but was '/petstore/openapi.json'
```
Identical to what CI reported here, and the rest of your run is clean: 69 of 71 passing, with the two failures in `rest-openapi`, which this PR does not touch.
## What is actually happening
The test expects two requests in order: a `GET /petstore/openapi.json` to fetch the specification, then the operation call. What arrives at the second expectation is **another spec fetch**, so the specification is being requested more than once and the operation request never shows up where the test waits for it.
Nothing in the Kamelet or the test changed. These integrations are executed by Camel JBang rather than by the project's `camel.version`, so they run against a moving Camel snapshot. The same tests passed on 2026-09-16 in CI and again locally on 2026-09-17; they fail today with no commit here in between, which points at a `camel-rest-openapi` behaviour change upstream rather than anything in this catalog.
That also puts the fix on the other side of the runtime boundary: `rest-openapi` is a Camel component, so if the repeated fetch is unintended it belongs in `apache/camel`.
## What this means for this PR
Nothing here needs changing on account of those two failures. They should not hold up review. I have flagged the breakage to @oscerd separately so it can be chased on its own rather than through your pull request.
---
_Claude Code on behalf of Andrea Cosentino_
--
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: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] CAMEL-24753: Add filter support to the langchain4j-ingest Kamelets [camel-kamelets]
Posted by "oscerd (via GitHub)" <gi...@apache.org>.
oscerd commented on PR #3033:
URL: https://github.com/apache/camel-kamelets/pull/3033#issuecomment-5773757201
Correction to my previous comment, and a fix.
I said the repeated specification fetch looked like a `camel-rest-openapi` behaviour change upstream. **That was wrong.** It is a race inside the test itself, and #3057 fixes it.
`rest-openapi-sink-route.yaml` drives both tests from a `timer-source` firing every ten seconds, and it keeps firing. Each test asserts one full cycle: fetch the specification, respond with it, then the operation call. When that cycle runs longer than the period, the next firing's specification fetch lands where the test is waiting for the operation, and the URI comparison fails.
What misled me was running it once on `main`, seeing the identical failure, and concluding it was deterministic. Repeating it showed otherwise: one failure then four passes on an unchanged tree, with durations straddling the ten second period. Had I repeated the run before writing, I would not have sent you upstream.
The part of my comment that stands is the part that matters here: **these two failures are not caused by your PR.** They reproduce on `main` without anything from your branch, and `rest-openapi` is untouched by the langchain4j change.
#3057 adds `repeatCount: 1` so the route sends exactly one message, which is what the assertions describe. Five consecutive runs pass, including runs of 23 and 25 seconds that would previously have been at risk. Once it lands, a rebase should turn this PR green.
---
_Claude Code on behalf of Andrea Cosentino_
--
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: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] CAMEL-24753: Add filter support to the langchain4j-ingest Kamelets [camel-kamelets]
Posted by "oscerd (via GitHub)" <gi...@apache.org>.
oscerd merged PR #3033:
URL: https://github.com/apache/camel-kamelets/pull/3033
--
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: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org