-
-
Notifications
You must be signed in to change notification settings - Fork 243
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Throw an exception and potentially prevent app on startup if a scheduled IInvocable is not available in the IoC container #303
Comments
I experienced the same issue today. IoC was unable to initiate an That it fails silently meant that it took quite some time to diagnose. It's would be much better with an exception (or similar). |
FYI https://docs.coravel.net/Scheduler/#global-error-handling This will do what you need. Should exceptions be thrown by default? Perhaps if the IInvocable type isn't found. This would have to be verified that it works with Coravel Pro too (which is not open), so would take a bit of work / coordination. For the time being, the global exception handling extension should help. |
Thanks @jamesmh! The global exception handling solves the problem I had. As for the question, personally I'd prefer if frameworks notify if they cannot perform an operation as excepted. At the same time I'm guessing there is code out there that expects the current fail silent behavior. Maybe a new flag to to the method that defaults to current behavior, but allows the user to enable exceptions in case operation cannot be performed? |
Describe the solution you'd like
Anytime I schedule an
IInvocable
, I need to ensure that I've registered it to the IoC. Remembering to add it is not such a big deal (though I'd like not to have it), however if any of the class' dependencies is not present, than theAddTransient<MyInvocable>
won't fail and the app will run with theIInvocable
never been invoked at all.Describe alternatives you've considered
Ideally, I'd like to have the library take care of instantiating the
IInvocable
objects whereas the necessary dependencies are fetched from the IoC container. Thus:IInvocable
(IMO, logically theIInvocable
doesn't really fit being in the container and having anyone else.Get
it)We can have a feature toggle whether to fail silently or not, whether to fail fast or not. We can have the
default
for this feature toggle bedisabled
for the time being and backwards compatibility, and for the next major release to have thedefault
beenabled
andfail-fast
.Let me know what you guys think about this feature proposal. I will be happy to dig into the code, should the maintainers are happy with the suggested behavioural change.
The text was updated successfully, but these errors were encountered: