davsclaus opened a new pull request, #29520: URL: https://github.com/apache/camel/pull/29520
_Claude Code on behalf of davsclaus_ A `wireTap` sends a copy of the message on another thread: the route goes on without waiting for the tapped route, and a failure there does not come back to it. The route readers of camel-jbang-core recorded a `wireTap` like a `to`, so the link kind came from the scheme alone, and a `wireTap` to a `direct` endpoint was a call. In the `route/enrich-and-dedupe` example, `wireTap: direct:audit` showed `audit` as `↳ audit` (a call that waits) under Routes in the About view, and the summary said the route "calls audit". - The YAML, XML and Java readers mark the endpoint a `wireTap` sends to (`Endpoint.tapped`). - `ProjectOverview` makes the link to a route reached by a wireTap a hand-off (`async`, `⇢`) where its scheme would make it a call. A route that also calls it with a `to` still calls it. - The About view, the Diagram and the summary follow from the link, with no change of their own. - The help of the Overview and the TUI observe page say a `wireTap` is `⇢` too. Tests: `ProjectOverviewTest.aWireTapHandsOffInEveryDsl` (YAML, XML, Java, and a route that both taps and calls). camel-jbang-core and camel-jbang-plugin-tui pass locally (the two `DoctorRepositoryTest` failures are of my local repository setup; they fail without this change too). 🤖 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]
