Workaround for launch bug #861
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kevin-bates
approved these changes
Oct 22, 2022
|
@meeseeksdev please backport to 7.x |
meeseeksmachine
pushed a commit
to meeseeksmachine/jupyter_client
that referenced
this pull request
Oct 24, 2022
blink1073
added a commit
that referenced
this pull request
Oct 24, 2022
Co-authored-by: Steven Silvester <steven.silvester@ieee.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
cc @kevin-bates
This prevents a race condition where the kernel launch process is attempting to read the connection file, and we overwrite the file while it is being read. The symptom is that the kernel fails to start because it cannot decode the JSON in the connection file.
We should backport this fix to 7.x, but I think for 8.x we should change it so that the provisioner is entirely responsible for the handling of the connection file, even if the information lives on the kernel manager. Nothing would change for the local provisioner.