-
Notifications
You must be signed in to change notification settings - Fork 290
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
index out of range
on (*Lifecycle).Stop()
#991
Comments
Thanks for reporting this. I'll try to repro this and triage this accordingly. |
@JacobOaks to take a look at this issue. |
Hey, So I looked at a couple ways this panic can occur, and they all involve using the lifecycle a little differently. Can you clarify a little more about how you're running your app so I can try to narrow down what's happening? Specifically:
Thanks! |
I am calling
Just
No, one instance of the application.
No custom timeouts but all of my hooks are long-running processes that require a specific startup and stop order. I was able to move past the issue, but I'm not sure how I fixed it because I don't quite understand what was causing it. |
Thanks for those details. For some context, fx keeps an internal counter that gets incremented for every This panic is occurring because when the app starts shutting down, this internal counter is larger than the actual number of registered hooks. Meaning an I'll keep looking into this to see if there's an internal bug that could cause these to be double-counted, but in the mean time, do you have any reason to believe your Also, if you have a code snippet showing exactly how you're catching the signal to stop the application, that could be useful. |
Unfortunately, I can't really provide a simple code snippet as it's a complex application, but based on your explanation of the problem, I agree that would be the case. Some of the issues that I had to struggle with were downstream libraries (re: NATS server) catching signals, stop hooks not having a matching start hook, and lazy constructor calling. I believe part of the reason this issue popped up is because the lifecycle concept I spent several years working in .NET, and one of the things I really came to appreciate was While I personally like the |
Currently, it is possible for a user to start their app (and thus its lifecycle) twice. This can lead to panics if the user has registered any lifecycle hooks (Ref: uber-go#991). This change will explicitly keep track of whether a lifecycle is currently running, under a lock, to ensure that the lifecycle can never be running twice at the same time.
@mxplusb thanks for the thoughtful feedback. I used to work on the .NET team at Microsoft, and am somewhat familiar with the HostBuilder interface. In Fx, the start/stop lifecycle hooks are executed separately from the dependency. The assumption here is that whatever you need to instantiate (such as the NATS server/client in the example you mentioned above) should be provided in the form of a I understand that coming from the .NET world this subtle difference can cause some confusion. Separately, thanks for reporting the panic! This issue did uncover a bug in the current implementation of lifecycle hook execution, so we will fix that panic shortly. |
Currently, there is nothing preventing somebody from making calls to `app.Start` and `app.Stop` when it doesn't make sense, for example calling `app.Start` or `app.Stop` twice, or trying to run the application twice concurrently. Because of this lack of control, it's possible for users to cause race conditions and panics (#991) by putting the lifecycle is strange positions. This PR places a small state machine in `Lifecycle` so that we can check if calls to `(*Lifecycle).Start` and `(*Lifecycle).Stop` make sense before going through. This will disallow starting an already starting/started app, and stopping an already stopping/stopped app. Tests to verify that are also added.
Closing this issue as we fixed the panic in #994. Thanks again for the report! |
Currently, there is nothing preventing somebody from making calls to `app.Start` and `app.Stop` when it doesn't make sense, for example calling `app.Start` or `app.Stop` twice, or trying to run the application twice concurrently. Because of this lack of control, it's possible for users to cause race conditions and panics (uber-go#991) by putting the lifecycle is strange positions. This PR places a small state machine in `Lifecycle` so that we can check if calls to `(*Lifecycle).Start` and `(*Lifecycle).Stop` make sense before going through. This will disallow starting an already starting/started app, and stopping an already stopping/stopped app. Tests to verify that are also added.
Describe the bug
When stopping the application with a
SIGINT
, the lifecycle hooks can panic.To Reproduce
Unclear, I'm not sure what's causing it. I would assume it's something to do with how the lifecycle hooks are registered.
Expected behavior
I expect it to error out instead of panicking.
Additional context
I am migrating an existing application to fx.
The text was updated successfully, but these errors were encountered: