LatentWorker do not insubstantiate at shutdown#2317
Conversation
we already stop the workers at stopService, which is called by the Application's hierarchy stop Doing the complicated SystemEventTrigger is just uneeded duplication
|
@tardyp, thanks for your PR! By analyzing the annotation information on this pull request, we identified @tomprince, @rutsky and @benallard to be potential reviewers |
| if self._substantiation_notifier: | ||
| # if master is stopping, we will never achieve consistent state, as workermanager | ||
| # wont accept new connection | ||
| if self._substantiation_notifier and self.master.running: |
There was a problem hiding this comment.
This is a fix for
|
Note that those fixes are not unit tested in this PR. They are tested in the tests for hyper. |
| from email.message import Message | ||
| from email.utils import formatdate | ||
|
|
||
| from future.utils import itervalues |
There was a problem hiding this comment.
this import order change seems to be unnecessary
There was a problem hiding this comment.
its made automatically by isort.
For some reason isort does not run on travis as it should, so we start taking technical debt about it.
That said. I would expect that future is part of the first. So maybe it is the config of my editor which cannot find the isort configuration
There was a problem hiding this comment.
ahah I did not see the build failure. So isort travis definitly work and my editor is misconfigured :-p
Current coverage is 85.95%@@ master #2317 diff @@
==========================================
Files 293 293
Lines 30455 30445 -10
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
- Hits 26175 26168 -7
+ Misses 4280 4277 -3
Partials 0 0
|
4 participants
we already stop the workers at stopService, which is called by the Application's hierarchy stop
Doing the complicated SystemEventTrigger is just uneeded duplication