jamesnetherton commented on code in PR #9040:
URL: https://github.com/apache/camel-quarkus/pull/9040#discussion_r3831263290
##########
extensions/langchain4j-ingest/runtime/src/main/java/org/apache/camel/quarkus/component/langchain4j/ingest/IngestRoutes.java:
##########
@@ -204,20 +220,49 @@ private void configureFileSource(String name,
IngestRunTimeConfig.PipelineRunTim
private void configureEndpointSource(String name, String uri,
IngestRunTimeConfig.PipelineRunTimeConfig runtime, IngestService
service) {
Expression documentId = documentIdExpression(runtime,
IngestHeaders.DOCUMENT_ID);
+ maybeAutoCreateRepository(name, runtime);
+ String repositoryName = runtime == null ? null :
runtime.source().idempotentRepository().orElse(null);
+ if (repositoryName == null) {
+ from(uri)
+ .routeId(routeId(name))
+ .process(exchange -> {
+ String id = requireDocumentId(name, documentId,
exchange);
+ exchange.getIn().setBody(service.ingest(id,
exchange.getIn().getBody(String.class)));
+ });
+ return;
+ }
+ // duplicates skip the block and the tail processor answers SKIPPED;
first write wins
+ // per id. The EIP keys on the validated id property, evaluating the
expression once
from(uri)
.routeId(routeId(name))
+ .process(exchange -> exchange.setProperty(DOCUMENT_ID_PROPERTY,
+ requireDocumentId(name, documentId, exchange)))
+ .idempotentConsumer(exchangeProperty(DOCUMENT_ID_PROPERTY),
Review Comment:
Question on the eager `idempotentConsumer` + first-write-wins interaction:
the key is added eagerly and `removeOnFailure` only releases it on an
*exception*. An `EMPTY`-outcome ingest (blank body) completes normally, so the
id stays claimed — a later non-blank document delivered under the **same id**
is then answered `SKIPPED` and never ingested.
This is consistent with the documented "first write wins per id", but here
the first write wrote nothing. If a source can legitimately deliver an
empty-then-populated document under a stable id, that content is lost silently.
Is that intended? If not, releasing the key on `EMPTY` (or not registering it)
would fix it. Either way, a one-line note in `usage.adoc` that an empty first
delivery still claims the id would help users.
##########
extensions/langchain4j-ingest/deployment/src/main/java/org/apache/camel/quarkus/component/langchain4j/ingest/deployment/Langchain4jIngestProcessor.java:
##########
@@ -73,6 +73,29 @@ AdditionalBeanBuildItem beans() {
.build();
}
+ /**
+ * {@code #class:} beans are instantiated reflectively, which native mode
allows only for
+ * registered classes: the two camel-core repositories the documentation
recommends, plus
+ * every {@code IdempotentRepository} implementation the Jandex index
knows — application
+ * classes always, third-party ones when their jar carries an index.
+ */
+ @BuildStep
+ void repositoryReflection(CombinedIndexBuildItem combinedIndex,
Review Comment:
Just flagging for awareness (you note native was verified, so likely fine):
`#class:` instantiation needs the no-arg constructor plus the property setters.
`.methods()` covers the setters and the builder registers constructors by
default, so this should be complete — correctness rests on those two facts
holding in the pinned Quarkus version, and on third-party repos shipping a
Jandex index (which the docs correctly call out). No change requested.
--
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]
