Based on recent work in this issue, it appears that an unhandled failure within a mutating Action callback will be logged by Pepr but then will not prevent further processing of the associated admission request.

See the commented out test in this Excellent Example for a reproduction of the described behavior (where the failing Mutation() of a delete request still allows the resource to be deleted).

This might be a problem for a few of reasons:

1. It is perfectly reasonable for a Module Author to want to run a series of mutating Action handlers against a resource in order to accomplish a desired goal and having one quietly fail while allowing others to act is likely to result in a resource with an intermediate state being submitted to the cluster.

2. Relying on Pepr logs -- which end user's aren't really expected to have to check -- to identify issues regarding a resource request that explodes a failed mutating callback is misleading to the user (at best) -- as the user-facing request (via HTTP / kubectl) will appear to succeed -- even though not all the registered mutations will have occurred.

3. Relying on Pepr logs to identify Action handler issues -- rather than rejecting admission requests outright -- loses out on the opportunity to provide direct feedback about errors occurring in the Pepr Action chain. This likely to greatly extend time-to-discovery of "bad handler" issues.