[
https://issues.apache.org/jira/browse/CAMEL-25390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18127602#comment-18127602
]
Claus Ibsen commented on CAMEL-25390:
-------------------------------------
PR: https://github.com/apache/camel/pull/27912
An action with a request id always gets an answer from the file transport: its
result, {{{"status":"failed","error":...}}} (with {{"reason":"not-found"}} when
what it was asked to work on does not exist), or {{{"status":"success"}}} when
it has no result. The shared action file of older Camel CLI versions keeps its
behaviour. Both transports share the mapping, the WebSocket frame gets the
reason too, the processor action now reports its errors and "No processor
matching", and an action file that cannot be read yet is retried for two
seconds. As agreed: status failed (the 4.23 shape) rather than status error,
and acks only on the request-id channel.
_Claude Code on behalf of davsclaus (Claus Ibsen)_
> camel-cli-connector - Always reply to CLI actions, including errors and acks
> ----------------------------------------------------------------------------
>
> Key: CAMEL-25390
> URL: https://issues.apache.org/jira/browse/CAMEL-25390
> Project: Camel
> Issue Type: Sub-task
> Components: camel-jbang
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.24.0
>
>
> * {{FileCliConnectorTransport}} always writes an output file: the result, or
> {{\{"status":"error","message":...,"action":...\}}} when the action reports
> an error via {{CliActionOutput.error()}}, the action is unknown, or dispatch
> throws.
> * Fire-and-forget actions (route start/stop/suspend/resume, processor
> enable/disable, gc, reload, reset-stats, logger) write an ack ({{status:
> success}} or the error).
> * Share the error mapping with {{WebSocketCliConnectorTransport}} so both
> transports behave the same.
> _Claude Code on behalf of davsclaus (Claus Ibsen)_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)