I just permanently lost access to an account because of this. ITS ABSURD.
I will throw hundreds of dollars at this problem. Jesus Christ. What do I have to do for someone to care about this or pay them to fix it?
The fact that the app just (a) drops updates on the ground if the server is unreachable, and (b) doesn’t bother trying to check for connectivity before doing things like provisioning passkeys is absurd.
The fact that your app returned back “passkey provisioned” when it HADNT EVEN SAVED IT, makes me so unsure of Bitwarden that I’m seriously considering migrating yet again.
Are you using the mobile app (as per the title and tags of this post), or the browser extension (as per your Github issue)?
If you’re serious about this, hire a freelance developer, and have them contribute a PR.
1 Like
Hi there, it looks like you’re using a third-party back-end, so it might be more helpful to connect with their community community spaces. In the meantime, your feedback has been passed along.
Hi folks. Happy to take this over to Vaultwarden.
Hopefully we all understand the basics of client/server communication though, and understand that the failure mode I’m describing here would identically affect users for any backend server. 
.
And this exact behavior happens across all operations, across all clients. It’s clear that intermittent network problems are not tested for, whatsoever.
Literally “can we actually hit the Bitwarden server before we provision a Passkey and report back to the caller that it provisioned successfully.”
At that point, it’s not even an annoyance, it’s a literal correctness issue. Bitwarden should not be telling ANY caller that it persisted a Passkey when it absolutely didn’t. That’s entirely client-side behavior.