UAT "aborts composition if editor exits abnormally" flaky

[romanofski]

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:

1. Run the test: PATH=path/to/purebred cabal v2-test uat --test-show-details=direct --test-options='-p "aborts composition"'
2. Alter the EDITOR env variable in the beginning of the test to a script which sleeps for a second and exits with 1
3. Test fails with: Condition not met: 'Substring "Editor exited abnormally", but it should have actually been met

Expected 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.

[romanofski]

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).

[romanofski]

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...

[romanofski]

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.

[romanofski]

I looked into this and it correlates heavily with our 500ms delay of the validation firing. My guess as to what happens here is:

• we enter the subject, a delayed validation is started
• we suspend brick to start the editor which in the reproducer case is a sleep 1s; exit 1
• now we have a race condition between rendering the error and rendering the queued validation

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.

[romanofski]

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.