Buttercup-desktop: Credentials not saved

[perry-mitchell]

This is a critical issue: credentials (new entry) are not saved.

[perry-mitchell]

Issue was during the autoupdate. Will watch for further problems.

[hugo-cardenas]

I actually spent some time today with this issue.
I noticed while in development at some point that entries were not being saved to disk after creating them and reloading (Ctrl+R) the Electron window.

The behaviour was so erratic that it took a while to identify a pattern, but I see this is reproduceable now in 0.25.1:

• Create an entry with just a title
• Lock the archive or View->Reload (here it seems it varies, I've got the issue basically always with Reloading, sometimes with Locking)
• Unlock the archive
• Entry is not there
• Quit the app -> now the saving popup keeps waiting forever.

[perry-mitchell]

I was able to reproduce this while I was back in Australia for Christmas. My server is in Helsinki so the latency was quite high compared to usual. I would add new items to a credential (new meta), save the changes and then immediately close.

The app closes straight away (no saving message), and the changes are not written to the remote.

[sallar]

@perry-mitchell then this is a huge problem. since we had those queues, it seems that they are not written to the queue. If you dont close the app immediately, are they written correctly?

[perry-mitchell]

Not 100% sure @sallar.. I'll try again on VPN shortly.

[perry-mitchell]

Ok, so this is still very much present.. I can confirm that it happens 100% of the time using a Dropbox archive, for example:

[perry-mitchell]

Ok so the Dropbox example has more far-reaching consequences. I can reproduce the credentials not saving locally by using the following steps:

1. Open dropbox archive
2. Create entry
3. After clicking save, close window immediately
4. Open bcup again
5. Open file archive (local)
6. Add new entry
7. It never saves (Closing the whole app at this stage results in the image below)

/cc @sallar

[sallar]

ok so when I call workspace save, it has three steps for saving:

sends an "enqueue" event to main thread which starts a promise inside the queue (of main thread), then the main thread's new promise sends back an ipc event to the "sender" window which is the 1st step in your instructions, which causes that to do the saving and then send back an event to main thread saying that its finished. but when you close the dropbox window too fast, it never gets a chance to tell the main thread that it finished that task (via an ipc event), so the task remains forever running in main thread's queue.

the solution is: we add the "please wait, saving" to the window close event, not the app close event.