Proposal: Opt-in for additional meaningful exit-codes

[lwc]

In handover we have some tasks that have various failure scenarios; sometimes it would be most appropriate to bury a task, other times it could be re-queued, maybe with a delay.

Currently cmdstalk is quite opinionated as to how to handle job failures, this one size fits all policy makes for a fine default, but it would be nice if cmdstalk supported some opt-in behaviour to allow the job command a little more control of the release strategy.

Exit codes are already meaningful, in that a non-zero code will cause cmdstalk to act based on it's opinion to either bury or release the task with a delay. With that in mind I propose allow that default behaviour to be extended, via additional args to cmdstalk, along the lines of:

cmdstalk -on-exit=255:BURY -on-exit=254:BACKOFF -on-exit=253:RELEASE ...

This would override the default cmdstalk exit code handling, which is still a valid use-case for when it is not possible to control the exit codes of the job command, with a more targeted approach that allows the job command input into what happens next.

Possible release / verbs would look something like (BURY, DELETE, RELEASE, BACKOFF) with backoff representing an (exponential) backoff strategy similar to cmdstalk's current default mode of operation.

[lox]

Would we pair that with exposing things like timeouts and buries to the app via ENV vars?

[lwc]

We could - do you think it would be necessary?

[pda]

Early thoughts:

I'd rather avoid cmdstalk invocations being essay-length.

I'd rather avoid applying non-standard meaning to exit status codes. Zero and non-zero are about the only ones anybody can agree upon.

What if cmdstalk used environment to tell the worker process about a means of sending richer control information? e.g. pass the path of a named pipe which the worker process can
echo bury > $CMDSTALK_CONTROL into, or
file_put_contents(getenv("CMDSTALK_CONTROL"), "bury"); or
File.open(ENV["CMDSTALK_CONTROL"], "w") { |f| f.puts("bury") } etc…

It remains unix-style, and simple enough to not require library support in the worker, and doesn't involve overloading magic numbers.

[joho]

I don't have feelings one way or another and will follow @lox's lead.

[lwc]

We discussed something similar - it's not exactly simpler than providing opt-in exit code behaviour, but it will get the job done. 👍

[lox]

IMO that solution is WAY more complicated than simply assigning strategies to exit codes in invocation.

[pda]

I can't come up with a rational reason for disliking meaningful exit codes.
If we use them, can I suggest:

• cmdstalk defines the codes, no giant CLI invocations to mess up.
• use codes < 128 so they work as both uint8 and int8
  • (or link to evidence showing that's unnecessary; I can't remember).

I should point out I'm responsible for exactly zero apps using cmdstalk,
so my opinions may be 🚲🏠

[lox]

Yeah, perhaps you are right. I'm torn. I don't like burying application logic in command-line invocations. POSIX message queues would be fairly straight-forward: http://php.net/manual/en/function.msg-get-queue.php