I've just spent the last couple hours trying to figure out an issue similar to #41 or actions/actions-runner-controller#2805.

The latter does not apply to my situation as I have a self-hosted cluster in microk8s which does not appear to have any sort of API rate limits.

While I have yet to figure out the true error, I'm fairly certain that this unhandled promise rejection is suppressing it, and it appears to be due to a misunderstanding in how a manually constructed Promise works in execPodStep():

The documentation for the Promise() constructor says this of the closure passed to it, which it calls executor: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/Promise#description

The executor return value is ignored. return statements within the executor merely impact control flow and alter whether a part of the function is executed, but do not have any impact on the promise's fulfillment value.

Since the closure is labeled async, it thus returns a Promise which is being ignored, which means if that exec.exec() call throws an exeception, it will lead to an unhandled promise rejection.

The invocation of exec.exec() should change to a chained style with an explicit .catch() call:

new Promise(function (resolve, reject) {
    exec.exec(/* args */)
        .catch(reject)
})

Or else the await exec.exec() statement should be wrapped in a try/catch.