Throw an exception and potentially prevent app on startup if a scheduled IInvocable is not available in the IoC container

[livanov]

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 the AddTransient<MyInvocable> won't fail and the app will run with the IInvocable 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:

1. The library will fail, if the configuration is not proper, instead of failing silently.
2. We don't have to remember to register the IInvocable (IMO, logically the IInvocable 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 be disabled for the time being and backwards compatibility, and for the next major release to have the default be enabled and fail-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.

[Turochamp]

I experienced the same issue today. IoC was unable to initiate an IInvocable instance and instead Coravel scheduling method silently failed.

That it fails silently meant that it took quite some time to diagnose. It's would be much better with an exception (or similar).

[jamesmh]

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.

[Turochamp]

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?