Attach event causing warning to "event after landing" event when saving .ork #2826
Conversation
This file contains hidden or 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
it'll be written after it in the .ork file
…he event after landing in the warning event. This is not ideal, as the event should logically be saved with the actual warning; however, this would require loading the event's UUID when the warning is loaded, and then replacing it with the actual event once it's loaded; this quickly got messier than the approach taken here.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
A sim warning event caused by an event after landing ends up having three parts:
The event triggering everything (for instance, a recovery deployment occurring after landing)
A warning about that event
A simulation warning event, caused by the warning.
Nothing was hooking the original event up to either the warning or the warning event in the .ork file; this ended up causing a null pointer exception.
With this PR, the original event and the warning are both hooked up to the sim warning event so the whole chain can be reconstructed. It would in a sense have been tidier to have hooked the original event up to the warning and the warning up to the sim warning event, but since warnings are saved in the .ork before events, this would have required saving the event's UUID with the warning until the event was loaded, which ended up seeming messier.
Note that a .ork file that was saved without hooking the original event up to the warning can be loaded (see @jimmiedave 's example in the original bug report), but the source of the sim warning doesn't appear in the warnings list. A .ork file saved with this PR does hook them up, and when the .ork is loaded the original event is reported properly.
Fixes #2804