Repository navigation
Expose a machine-readable error for file retrieval failures (jobout, script, job) #526
Description
Warning
Agentic issue
Summary
Clients cannot distinguish "this node's file is not available" from other server errors without parsing the free-text reply. A machine-readable signal would let a client decide, for example, whether to fall back to a log server.
Current behaviour
ErrorCmd carries only a free-text message (libs/base/src/ecflow/base/stc/ErrorCmd.hpp, error_msg_), so every failure arrives as one untyped string. For example, with ecflow 5.15.2 over HTTP:
# node does not exist
Server reply: Cannot find node at path '/test_suite/no_such_file'
# node exists but its job output is not on the server host
Server reply: Failed to open the job-out(ECF_JOBOUT=ECF_HOME/ECF_NAME.ECF_TRYNO='/home/ecflow/server/test_suite/setup/init.0') for task /test_suite/setup/init (No such file or directory)
A client that wants to treat "file unavailable" differently from "node unknown", "permission denied" or "server error" has to match those strings, which is brittle across releases and locales and easy to get wrong.
Request
Please expose a stable, machine-readable classification for file retrieval failures, for example:
- an error code or enum on
ErrorCmd(with0/okfor success), or - a dedicated reply/status for "requested file is not available on the server host", or
- a documented, stable substring contract for these messages, if a code is not feasible.
The specific case that prompted this is FileCmd with File::JOBOUT (and the equivalent script/job types) where the file is genuinely absent on the server host, as opposed to a node or permission error.
Activity