Describe the bug
An HTTP trigger's error_handler_path is accepted at write time in the script/f/... form, but at runtime the script/ prefix is not stripped — it is searched for as part of the script name, so the handler never runs.
The failure only surfaces when an error actually occurs, which is precisely when the handler is supposed to help.
To reproduce
Create an HTTP trigger with an error_handler_path, then make the target script fail.
error_handler_path value |
Result |
script/f/test/error_handler |
accepted, but at runtime: Not found: script not found at name script/f/test/error_handler |
f/test/error_handler |
handler runs correctly |
With the bare path the handler runs as expected:
HANDLER pfad=f/test/effect is_flow=false job=01a0269f
Expected behavior
Either strip a leading script/ when resolving the path, or reject the value at write time with a clear message.
Screenshots
No response
Browser information
Not applicable — reproduced via API.
Application version
CE v1.792.2 (self-hosted, Docker Compose)
Additional Context
The trap is that script/f/... is the spelling used elsewhere in the product, so it is a natural thing to write. The value is accepted, stored, and reads back fine — everything looks correct until the error path is exercised for the first time in production.
Two smaller observations from the same test pass on HTTP triggers, happy to split out if useful:
- A newly created route returns
404 Trigger not found at name /test/inbox for roughly 10 seconds after creation, even though the trigger already appears in the list. Routes appear to be cached in memory and refreshed on an interval.
update requires fields that create populated itself. Omitting raw_string surfaces a raw database error: SqlErr: null value in column "raw_string" violates not-null constraint.
Describe the bug
An HTTP trigger's
error_handler_pathis accepted at write time in thescript/f/...form, but at runtime thescript/prefix is not stripped — it is searched for as part of the script name, so the handler never runs.The failure only surfaces when an error actually occurs, which is precisely when the handler is supposed to help.
To reproduce
Create an HTTP trigger with an
error_handler_path, then make the target script fail.error_handler_pathvaluescript/f/test/error_handlerNot found: script not found at name script/f/test/error_handlerf/test/error_handlerWith the bare path the handler runs as expected:
Expected behavior
Either strip a leading
script/when resolving the path, or reject the value at write time with a clear message.Screenshots
No response
Browser information
Not applicable — reproduced via API.
Application version
CE v1.792.2 (self-hosted, Docker Compose)
Additional Context
The trap is that
script/f/...is the spelling used elsewhere in the product, so it is a natural thing to write. The value is accepted, stored, and reads back fine — everything looks correct until the error path is exercised for the first time in production.Two smaller observations from the same test pass on HTTP triggers, happy to split out if useful:
404 Trigger not found at name /test/inboxfor roughly 10 seconds after creation, even though the trigger already appears in the list. Routes appear to be cached in memory and refreshed on an interval.updaterequires fields thatcreatepopulated itself. Omittingraw_stringsurfaces a raw database error:SqlErr: null value in column "raw_string" violates not-null constraint.