Right now we do not ask for globals to return a result (mainly because they are long running and should run the entirety of the application).
That being said, in the scenario that a global panics, because that global is run in a separate thread, we do not have a way to catch that panic and mitigate it. E.g. consider the scenario where a global panics in a scenario where we want to absolutely restart the entire application. The way that globals are implemented currently makes that impossible.
When we do implement this, it is going to also require adding a config option for managing globals (we could make this an option on a per-global basis, i.e. when we register the global allow for a boolean to be set that determines whether or not a panic'd global causes the application as a whole to panic. We will also want to make sure logging in fixed in the scenario where a global is canceled due to timeout (stop token) vs panics.
Right now we do not ask for globals to return a result (mainly because they are long running and should run the entirety of the application).
That being said, in the scenario that a global panics, because that global is run in a separate thread, we do not have a way to catch that panic and mitigate it. E.g. consider the scenario where a global panics in a scenario where we want to absolutely restart the entire application. The way that globals are implemented currently makes that impossible.
When we do implement this, it is going to also require adding a config option for managing globals (we could make this an option on a per-global basis, i.e. when we register the global allow for a boolean to be set that determines whether or not a panic'd global causes the application as a whole to panic. We will also want to make sure logging in fixed in the scenario where a global is canceled due to timeout (stop token) vs panics.