OK, I think I've figured out Brendan's crash in comment 63, and I'm not totally sure it's the same issue, although it definitely gives me some ideas. ``` ./mach mochitest --headless comm/mail/base/test/browser/browser_archive.js ``` I'll spare the gory details (soooooo much printf debugging!), but the upshot is that the test deletes (archives) a thread, then clicks "undo". It then waits until it sees an item appear in back the thread tree. Buuuuut... if you augment the test to have more messages in the thread, the undo (really a message copy) operation is still running when the test end conditions are met. The test then ends, and the test cleanup code is run. And the cleanup code deletes the account being used for the test - which includes the incomingserver and its msgStore. So it's no wonder we get catastrophic failure :-) As a side note, the existing code in `browser_archive.js` uses a thread with 2 messages in it. I'd kind of expect that to suffer the same issue (the cleanup happening before the undo operation is complete). But maybe with 2 messages it completes quickly enough that the timing doesn't become an issue? In any case, I think it'd be worth seeing if that test can be changed to ensure all the messages have been copied back before finishing the test. The line in question is: https://searchfox.org/comm-central/source/mail/base/test/browser/browser_archive.js#93 It seems like this'd be a prime "intermittant failure" kind of thing... Brendon: I'm not sure if you dug far into this test, just NIing you on the off chance you know all about it :-) Geoff: any opinion on this test? Seems to me that it should wait until all the messages appear back in the gui, but I've no idea how you'd go about doing that...
Bug 1749276 Comment 65 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
OK, I think I've figured out Brendan's crash in comment 63, and I'm not totally sure it's the same issue, although it definitely gives me some ideas. ``` ./mach mochitest --headless comm/mail/base/test/browser/browser_archive.js ``` I'll spare the gory details (soooooo much printf debugging!), but the upshot is that the test deletes (archives) a thread, then clicks "undo". It then waits until it sees an item appear in back the thread tree. Buuuuut... if you augment the test to have more messages in the thread, the undo (really a message copy) operation is still running when the test end conditions are met (at least one message has been re-instated, but the rest are still in-progress). The test then ends, and the test cleanup code is run. And the cleanup code deletes the account being used for the test - which includes the incomingserver and its msgStore. So it's no wonder we get catastrophic failure :-) As a side note, the existing code in `browser_archive.js` uses a thread with 2 messages in it. I'd kind of expect that to suffer the same issue (the cleanup happening before the undo operation is complete). But maybe with 2 messages it completes quickly enough that the timing doesn't become an issue? In any case, I think it'd be worth seeing if that test can be changed to ensure all the messages have been copied back before finishing the test. The line in question is: https://searchfox.org/comm-central/source/mail/base/test/browser/browser_archive.js#93 It seems like this'd be a prime "intermittant failure" kind of thing... Brendon: I'm not sure if you dug far into this test, just NIing you on the off chance you know all about it :-) Geoff: any opinion on this test? Seems to me that it should wait until all the messages appear back in the gui, but I've no idea how you'd go about doing that...
OK, I think I've figured out Brendan's crash in comment 63, and I'm not totally sure it's the same issue, although it definitely gives me some ideas. ``` ./mach mochitest --headless comm/mail/base/test/browser/browser_archive.js ``` I'll spare the gory details (soooooo much printf debugging!), but the upshot is that the test deletes (archives) a thread, then clicks "undo". It then waits until it sees an item appear in back the thread tree. Buuuuut... if you augment the test to have more messages in the thread, the undo (really a message copy) operation is still running when the test end conditions are met (at least one message has been re-instated, but the rest are still in-progress). The test then ends, and the test cleanup code is run. And the cleanup code deletes the account being used for the test - which includes the incomingserver and its msgStore. So it's no wonder we get catastrophic failure :-) As a side note, the existing code in `browser_archive.js` uses a thread with 2 messages in it. I'd kind of expect that to suffer the same issue (the cleanup happening before the undo operation is complete). But maybe with 2 messages it completes quickly enough that the timing doesn't become an issue? In any case, I think it'd be worth seeing if that test can be changed to ensure all the messages have been copied back before finishing the test. The line in question is: https://searchfox.org/comm-central/source/mail/base/test/browser/browser_archive.js#93 It seems like this'd be a prime "intermittant failure" kind of thing... Brendon: I'm not sure if you dug far into this test, just NIing you on the off chance you know all about it :-) Geoff: any opinion on this test? Seems to me that it should wait until all the messages of the thread re-appear in the gui, but I've no idea how you'd go about doing that...