Transaction returned to "start payment2 status after PC restarted

[Stam57]

SUPPORT REQUESTS: This is for reporting bugs in the Bisq app.
If you have a support request, please join #support on Bisq's
Keybase team at https://keybase.io/team/Bisq

Description

Last night I completed the transaction by paying the seller. The seller verified the payment and I received in my phone a 'transaction complete' message through the bisq app. I never visited the bisq app in my PC after that until this morning when I realised that the PC had done an automatic restart because of some new windows updates. When I opened bisq in the PC I received a warning message about the time left to complete the transaction. I pressed the 'payment started' button and then I received the warning about the bug.

Version

1.4.2

Steps to reproduce

as in description above

Expected behaviour

the transaction should have been ended and completed

Actual behaviour

the transaction returned to a previous step (step 2: start payment)

Screenshots

Screenshots if gui related, drag and drop to add to the issue

Device or machine

windows 10, intel CPU

Additional info

Additional information useful for debugging (e.g. logs)
bisq2.log

[ghost]

From looking at the log, you had two trades (NPNOY and 89599304) which successfully completed & paid to your wallet; then at midnight your machine did an automatic reboot. When Bisq was started again the trades erroneously reverted to an earlier state. I am investigating this as it looks like a bug. I'll attempt to reproduce the error and update here with any progress. Thanks.

[ghost]

This is reproducible by killing the Bisq process without allowing it to do a graceful shutdown, which is what the Windows midnight reboot did. The trade state was not able to be saved to disk, so upon startup the last-saved state was back at when the trade was created. However it does fully recover after pressing start payment again, it goes straight to the final stage which is send funds to external address / keep funds in Bisq wallet.

Given that the scenario is quite rare, and that it does recover quite gracefully I would lean towards not spending resources on developing and testing a fix.

Alternatively, a simple fix may be to call requestPersistence after each state change.

@chimp1984 opinions?

[chimp1984]

@jmacxx Ah thanks for finding out the issue! I suspected that there are hard shutdown scenarios where the peristence at shutdown does not get triggered.
requestPersistence is called but the actual write to disk has quite long periods not as the write at shutdown was considered safe, but it seems its not enough. I will make a PR for decreasing the periods so the cases where such could happen gets reduced a lot (we do not want to safe to often as thats a major performance issue specially on non ssd disks).

[Stam57]

If I remember correctly I pressed the 'Payment was sent' (or whichever similar button Bisq shows to proceed to the 3rd stage of the transaction (verification from other trader)) , but instead of advancing the transaction to the final stage it produced the error message. That is why I opened the issue here (as it was suggested by the Bisq error message).

This is reproducible by killing the Bisq process without allowing it to do a graceful shutdown, which is what the Windows midnight reboot did. The trade state was not able to be saved to disk, so upon startup the last-saved state was back at when the trade was created. However it does fully recover after pressing start payment again, it goes straight to the final stage which is send funds to external address / keep funds in Bisq wallet.

Given that the scenario is quite rare, and that it does recover quite gracefully I would lean towards not spending resources on developing and testing a fix.

Alternatively, a simple fix may be to call requestPersistence after each state change.

@chimp1984 opinions?

[chimp1984]

It is likely that the app when MS killed it at the update process did not persist its state and that caused follow up errors when starting again. I made a PR for fixing that for next release.

[cd2357]

As per the comment above, a fix was introduced end of 2020.

@Stam57 if you're still seeing the issue in the latest version of Bisq, let us know.