bug: five settings are accepted and persisted but have no runtime effect

Describe the bug

Five settings can be set, are persisted, and read back correctly via the API — but have no effect at runtime. They fail silently, which makes them worse than a missing feature: an operator configures them, verifies they are stored, and reasonably concludes the system is protected.

Setting	Level	Observed effect
Error handler	Workspace	none — never fires
on_failure	Schedule	none — never fires
concurrent_limit	Script and Flow	none — no limiting observed
cache_ttl	Flow step	none (on a script it works correctly)
delete_after_secs	Flow	none — nothing is deleted

Filing these together because the pattern is the actual finding — there is no obvious rule that predicts which fields are wired up. Happy to split into separate issues if that is easier to triage.

To reproduce

Each was tested with a control run — once with the setting, once without — since testing only the configured case measures the environment rather than the setting.

delete_after_secs is the clearest to reproduce: set it to 30 on a flow, deploy, confirm via API that delete_after_secs = 30 is returned. Run the flow. After 160 seconds: flow job present, result present, step job present, flow status present. Nothing deleted, nothing redacted.

concurrent_limit: set on both a script and a flow, then start more runs than the limit allows. All run concurrently.

cache_ttl: has no effect when set on a flow step; the same value in a script's script.yaml correctly freezes results.

Error handler / on_failure: neither the workspace error handler nor a schedule's on_failure runs when a job fails. Note that the error_handler_path on an HTTP trigger does fire correctly with the same bare path format (f/foo/handler), so path formatting is not the cause here.

Expected behavior

Either the settings take effect, or they are rejected at write time.

Screenshots

No response

Browser information

Not applicable — reproduced via API.

Application version

CE v1.792.2 (self-hosted, Docker Compose)

Additional Context

For contrast, these were verified to work correctly in the same test pass: timeout, retry, suspend, mock, continue_on_error and skip_failures on a step, same_worker on a flow, and cache_ttl on a script.

There is no discernible pattern — it is not "all flow-level fields" or "all workspace settings". same_worker is flow-level and works; concurrent_limit is script-level and does not.

Possibly related to #7311 and #5453 for the error-handler part.