Why should serviceGroup register onto shutdownListener instead of wrapListener?

[cyb0225]

have read the source code of go-zero regarding graceful shutdown. And this is my blog summary of go-zero's graceful shutdown feature.
https://github.com/zeromicro/go-zero/blob/fafbee24b891f6c6450b6ecbe2ba5ea19b99daf9/core/proc/shutdown.go#L1-L100

I think that the design of two staggered shutdown phases （wrapUpTime and waitTime ）in the code review was due to consideration of dependency issues. The HTTP service depends on various components such as MySQL, logging, etc. If these basic components are closed before the HTTP service, it will also lead to request processing failure. Therefore, HTTP and RPC services should be closed first. It's like a stack, with the dependencies loaded first closed last. I saw that the code does indeed do it this way.

I found that the serverGroup was registered onto shutdownListener. https://github.com/zeromicro/go-zero/blob/fafbee24b891f6c6450b6ecbe2ba5ea19b99daf9/core/service/servicegroup.go#L52-L59

In my understanding, serviceGroup is used to register services other than http and rpc, such as job and task. Therefore, I believe that they should also be released as a first batch, instead of being released together with the basic components. Currently, the release is carried out in a concurrent coroutine manner, which may result in each serviceGroup and basic component not knowing which one is released first, leading to the possibility of exceptions in processing.

I see that the comment for waitTime is set based on the query, so it may be appropriate to include serviceGroup in the shutdown process. I'd like to ask how to handle exceptions caused by write requests during graceful shutdown? Will they be ignored?

My idea may be naive, but I still hope to get your reply to solve my confusion. Thank you very much. And I sincerely hope that go-zero can continue to develop and thrive.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.