Don't print heimdall stack on errors #6778
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
Currently this is error-prone. The stack is useful for understanding
error cases but it needs to be made more resilient first.
The error case is as follows
1. build_1
a. something in build adds to the stack and then errors, leaving the
stack unbalanced.
b. stopAndReport(build_1) fails to stop the node.
2. build_2
a. start(build_2) now detachs a node it thought was not active, but
because of the prior stop failure, it is still active. When the
new build node is added, it is a descendant of the build_1 node.
b. something in the build adds to the stacka nd then errors, leaving
the stack unbalanced.
c. now the stack is detached, an error case.
The better solution here is for stop in 1b. to work even when
unbalanced. What should be done
1. stopping nodes autocloses the stack to the current node.
2. analysis tools (eg rob's visualizer) check for autoclosed nodes and
highlight the nearest un-autoclosed ancestor
rwjblue
approved these changes
Feb 15, 2017
|
@homu r+ |
|
📌 Commit 02ddb29 has been approved by |
|
⚡ Test exempted - status |
homu
added a commit
that referenced
this pull request
Feb 15, 2017
…-error, r=rwjblue Don't print heimdall stack on errors Currently this is error-prone. The stack is useful for understanding error cases but it needs to be made more resilient first. The error case is as follows 1. build_1 a. something in build adds to the stack and then errors, leaving the stack unbalanced. b. stopAndReport(build_1) fails to stop the node. 2. build_2 a. start(build_2) now detachs a node it thought was not active, but because of the prior stop failure, it is still active. When the new build node is added, it is a descendant of the build_1 node. b. something in the build adds to the stacka nd then errors, leaving the stack unbalanced. c. now the stack is detached, an error case. The better solution here is for stop in 1b. to work even when unbalanced. What should be done 1. stopping nodes autocloses the stack to the current node. 2. analysis tools (eg rob's visualizer) check for autoclosed nodes and highlight the nearest un-autoclosed ancestor
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.
Currently this is error-prone. The stack is useful for understanding error cases but it needs to be made more resilient first.
The error case is as follows
a. something in build adds to the stack and then errors, leaving the stack unbalanced.
b. stopAndReport(build_1) fails to stop the node.
a. start(build_2) now detachs a node it thought was not active, but because of the prior stop failure, it is still active. When the new build node is added, it is a descendant of the build_1 node.
b. something in the build adds to the stacka nd then errors, leaving the stack unbalanced.
c. now the stack is detached, an error case.
The better solution here is for stop in 1b. to work even when unbalanced. What should be done