Does setFailed just set the failure state and continue? (ie, it doesn't throw an exception or otherwise trampoline out of here). If so, I think that we should make it explicit that we're going to keep going, which wasn't obvious to me at first reading. I think that we should either return here or hoist the debug messages up above it so that it's more clear that they will always be executed.

Yes, setFailed sets the failing exit code per https://github.com/actions/toolkit/tree/master/packages/core#exit-codes

Thanks for the ping - sorry that I forgot about this issue.

To clarify - my question isn't whether setError sets the error code. My question was whether it stops execution, which it looks to me like it does not? Shouldn't we follow up setError with a process.exit or something along those lines instead of continuing on?

yes if you use setFailed and the user hasn't set any 'continue on error' values in their workflow, then it will fail the action step.

I don't mean the workflow step - I mean the action itself. What I mean is that calling core.setFailed just sets the error message and exit status and then the process itself will just continue. So you need to stop the process, that's why I was throwing.

See https://github.com/ethomson/test and https://github.com/ethomson/test/runs/1645271583?check_suite_focus=true for an illustration of what I mean.

Ah, got it now -- sorry I misunderstood what you were pointing out. I think throwing the errors then on validating input probably still makes sense. Since run() is the only real function afterwards and the last code execution is the result of the update post, the setFailed there probably makes sense to leave as is, as you'd be throwing to the end of execution anyway.

So an update could be to setFailed and throw on the validateInput function, and just keep setFailed on run() since it's the last execution.

Either way I get what you're saying now.