See #415
In order to not break the API I'm proposing that we allow errors to be accessible or accumulated in the config.Config context struct. This would allow us to support placing errors mid-framework calls and check for them later. The best example of this is the HTTP client timeout, which right now is unable to be handled and will incorrectly cause an exploit to "fail" even if callbacks have occurred. If we had support for this we could trivially check if the client error was a timeout type and then proceed to success vs false failing.
See #415
In order to not break the API I'm proposing that we allow errors to be accessible or accumulated in the
config.Configcontext struct. This would allow us to support placing errors mid-framework calls and check for them later. The best example of this is the HTTP client timeout, which right now is unable to be handled and will incorrectly cause an exploit to "fail" even if callbacks have occurred. If we had support for this we could trivially check if the client error was a timeout type and then proceed to success vs false failing.