oscerd opened a new pull request, #27477:
URL: https://github.com/apache/camel/pull/27477
# CAMEL-23458: camel-docling - add consumer support for async task
completion events
`camel-docling` was producer-only: `DoclingEndpoint.createConsumer()` threw,
so a route that wanted to act on an
async conversion had to poll `CHECK_CONVERSION_STATUS` by hand. This adds an
event-driven consumer.
## What this adds
A **scheduled polling consumer** that drains the component-wide registry of
tasks submitted via
`SUBMIT_ASYNC_CONVERSION` (the in-memory
`DoclingComponent.pendingAsyncTasks` map) and emits one exchange as each task
completes:
```java
from("direct:submit")
.to("docling:convert?useDoclingServe=true&operation=SUBMIT_ASYNC_CONVERSION");
from("docling:onComplete?useDoclingServe=true&delay=5000")
.to("mock:done");
```
- a **successful** conversion carries the converted content as the body —
the same shape the synchronous `CONVERT_*`
operations produce for the configured `outputFormat` — plus the task id in
the `CamelDoclingTaskId` header;
- a **failed** conversion completes the exchange with the underlying
exception, so the route's `onException` applies;
- the completed task is claimed atomically (`remove(key, value)`) so a
concurrent `CHECK_CONVERSION_STATUS` or another
consumer cannot emit it twice.
## Design notes
- The two viable strategies in the issue were polling and webhook; docling's
async tasks are SDK `CompletableFuture`s
held in-memory on the component, so the **polling** strategy fits (there
is no server-side task list to webhook from).
- `DoclingEndpoint` now extends `ScheduledPollEndpoint` (was a producer-only
`DefaultEndpoint`), which gives the
poll-interval configuration (`delay`, `initialDelay`, `useFixedDelay`,
...) for free.
- The content extraction shared by the synchronous operations and the
consumer was moved into a small
`DoclingContentExtractor` util, so both yield the same body for a given
`outputFormat` (no duplication).
- Security: the consumer adds no new input/output surface — it only drains
conversions already submitted through the
existing producer path.
## Tests & docs
- `DoclingConsumerTest` — a completed conversion is emitted to the route
with the converted body and drained from the
map.
- `DoclingConsumerFailureTest` — a conversion that completed exceptionally
is routed to `onException`.
- `DoclingConsumerIT` — end-to-end against a real docling-serve (submit
async → consume completion); disabled on CI like
the other docling ITs, so the deterministic failure path is covered by the
unit test above.
- `docling-component.adoc` documents the consumer with a worked example.
`main` only.
---
_Claude Code on behalf of oscerd_
🤖 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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
