Closed romanofski closed 1 year ago
Hm.. yes can confirm. It has something to do that the error message was created from a widget which isn't displayed any more. So either it must be created with the widget reference from the previous view which isn't available in the composition view any more, because that's the view which is displayed after the editor. The only reason why it sometimes works perhaps is if the widget reference already is from the composition? (e.g. when I manually try it out).
Hm.. on a second thought, looking into the code displaying the errors: when the editor is invoked, any error message due to abnormal termination is displayed in the StatusBar
which is visible in all views...
Ok back to square one, my comment https://github.com/purebred-mua/purebred/issues/429#issuecomment-813227871 was made based on the wrong setup.
I must have reverted the test back to it's initial form making it pass.
I looked into this and it correlates heavily with our 500ms delay of the validation firing. My guess as to what happens here is:
sleep 1s; exit 1
If I "wait" 500ms after entering the "To" line, just before the subject line, I get a passing test. If I don't, it fails on expecting the Editor exited abnormally
.
Actually just realising that the Subject
doesn't have validation. So it really is the validation from the To
input field delayed by 500ms. If we step too quickly it will race with rendering the error.
Describe the bug The UAT ""aborts composition if editor exits abnormally" is flaky depending on how quickly the shell can figure out that the editor does not exist.
To Reproduce Steps to reproduce the behavior:
PATH=path/to/purebred cabal v2-test uat --test-show-details=direct --test-options='-p "aborts composition"'
EDITOR
env variable in the beginning of the test to a script which sleeps for a second and exits with1
Condition not met: 'Substring "Editor exited abnormally"
, but it should have actually been metExpected behavior Test passes successfully.
Screenshots None
Additional context I wonder whether it has something to do with how we show error messages. The fix for #412 prevents that error messages are shown in views/widgets which aren't displayed any more. I wonder whether that checks fails when we spawn a subcommand and suspend brick causing the error message to not appear.