@brandur while working on some stuff in the demo tonight, I realized that the hard stop was no longer working correctly if initiated after a soft Stop() was ongoing. I believe a regression or at least a change in behavior occurred with https://github.com/riverqueue/river/issues/272, because the shutdown logic in the demo app used to properly handle these shutdown scenarios.
Perhaps this isn't exactly a "bug", though it did used to work this way. In the past you didn't need to cancel the context for Stop() prior to calling StopAndCancel(), but now it appears that is required. This is because the start/stop service has a mutex which is held while Stop() is ongoing and so a subsequent concurrent call to StopAndCancel() cannot proceed until that first call has been "released" by cancelling its context.
I didn't have time to get any further on this tonight but figured you might have thoughts.
@brandur while working on some stuff in the demo tonight, I realized that the hard stop was no longer working correctly if initiated after a soft
Stop()was ongoing. I believe a regression or at least a change in behavior occurred with https://github.com/riverqueue/river/issues/272, because the shutdown logic in the demo app used to properly handle these shutdown scenarios.Perhaps this isn't exactly a "bug", though it did used to work this way. In the past you didn't need to cancel the context for
Stop()prior to callingStopAndCancel(), but now it appears that is required. This is because the start/stop service has a mutex which is held whileStop()is ongoing and so a subsequent concurrent call toStopAndCancel()cannot proceed until that first call has been "released" by cancelling its context.I didn't have time to get any further on this tonight but figured you might have thoughts.