Use deferred for action dispatcher initialization #405
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What it does
Fixes a problem in the action dispatcher initialization that was introduced with #402.
Due to the change from async registry provider to direct registry injection it was possible to end up in a dead lock if there was an action handler was registered that listened to the
SetModelAction
and dispatches a response action.(This handler would already been triggered during the initialization phase because an empty set model action is dispatched there, the corresponding initializationPromise was not defined at this point -> initialize logic is called again).
Solved by using a proper deferred for the initialization step.
How to test
Should not be required as the change is rather simple and straightforward. However, if needed this can be done by registering a custom action handler in the standalone app:
Observe that with this handler the application loading fails on master, but still works in this PR.
Follow-ups
Changelog