Bug 1853821 Comment 6 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

It looks like the updated behaviour will also affect this test (https://searchfox.org/mozilla-central/source/toolkit/mozapps/update/tests/unit_base_updater/marFileLockedFailureComplete_win.js#16).
Unlike the previous test we handled in D214179 this is actually simulating a write error (with the case where .mar is locked), I'm wondering if we can change the test so I verify handleFallbackToCompleteUpdate() is called instead of checking if the state falls back to pending?
It looks like the updated behaviour will also affect this test (https://searchfox.org/mozilla-central/source/toolkit/mozapps/update/tests/unit_base_updater/marFileLockedFailureComplete_win.js#16).
Unlike the previous test we handled in D214179 this is actually simulating a write error (with the case where the .mar file is locked), I'm wondering if we can change the test so I verify if handleFallbackToCompleteUpdate() is called, instead of checking if the state falls back to pending?
It looks like the updated behaviour will also affect this test (https://searchfox.org/mozilla-central/source/toolkit/mozapps/update/tests/unit_base_updater/marFileLockedFailureComplete_win.js#16, and the equivalent in unit_service_updater).
Unlike the previous test that we handled in D214179 this is actually simulating a write error (with the case where the .mar file is locked), I'm wondering if we can change the test so I verify if handleFallbackToCompleteUpdate() is called, instead of checking if the state falls back to pending?
It looks like the updated behaviour will also affect this test (https://searchfox.org/mozilla-central/source/toolkit/mozapps/update/tests/unit_base_updater/marFileLockedFailureComplete_win.js#16, and the equivalent in unit_service_updater).
Unlike the previous test that we handled in D214179 this is actually simulating a write error (with the case where the .mar file is locked), I'm wondering if we can change the test so I verify if handleFallbackToCompleteUpdate() is called after the update is applied, instead of checking if the state falls back to pending?

Back to Bug 1853821 Comment 6