Unable to update cipher after editing attachments using Desktop client #1104

Closed
opened 2025-10-09 17:03:55 +03:00 by OVERLORD · 7 comments
Owner

Originally created by @Nyxtorm on GitHub.

Originally assigned to: @BlackDex on GitHub.

Subject of the issue

  • Unexpected behavior when deleting an attachment
  • Problem of editing and deleting an attachment at the same time

Deployment environment

  • Vaultwarden version: v1.25.0-af50eae6
  • Web-vault version: v2022.6.0 (compiled w/ PR72)
  • Running within Docker: false (Base: Debian)
  • Environment settings overridden: false
  • Uses a reverse proxy: true
  • IP Header check: true (X-Real-IP)
  • Internet access: true
  • Internet access via a proxy: false
  • DNS Check: true
  • Time Check: true
  • Domain Configuration Check: true
  • HTTPS Check: true
  • Database type: SQLite
  • Database version: 3.35.4
  • Clients used: Web, Android, Windows, Chrome, Firefox
  • Reverse proxy and version: Nginx 1.21.6
  • Other relevant information:

Steps to reproduce

  1. Create an item with an attachment
  2. Edit the item
  3. Delete the attachment, confirm deletion
  4. Before save & close, change any other field
  5. Click on save to finish editing the item, error occurs : https://i.imgur.com/63SzWOq.png

Expected behaviour / Actual behaviour

If the deletion of the attachment has already been taken into account on the server side, there should be no error here.
It is currently impossible to edit a field and delete an attachment at the same time.

Troubleshooting data

  • Image 01 : https://i.imgur.com/63SzWOq.png
  • Sorry, I couldn't test on the official version because I don't have my premium subscription anymore, so I can't add attachments.
Originally created by @Nyxtorm on GitHub. Originally assigned to: @BlackDex on GitHub. ### Subject of the issue * Unexpected behavior when deleting an attachment * Problem of editing and deleting an attachment at the same time ### Deployment environment * Vaultwarden version: v1.25.0-af50eae6 * Web-vault version: v2022.6.0 (compiled w/ PR72) * Running within Docker: false (Base: Debian) * Environment settings overridden: false * Uses a reverse proxy: true * IP Header check: true (X-Real-IP) * Internet access: true * Internet access via a proxy: false * DNS Check: true * Time Check: true * Domain Configuration Check: true * HTTPS Check: true * Database type: SQLite * Database version: 3.35.4 * Clients used: Web, Android, Windows, Chrome, Firefox * Reverse proxy and version: Nginx 1.21.6 * Other relevant information: ### Steps to reproduce 1. Create an item with an attachment 2. Edit the item 3. Delete the attachment, confirm deletion 4. Before save & close, change any other field 5. Click on save to finish editing the item, error occurs : https://i.imgur.com/63SzWOq.png ### Expected behaviour / Actual behaviour If the deletion of the attachment has already been taken into account on the server side, there should be no error here. It is currently impossible to edit a field and delete an attachment at the same time. ### Troubleshooting data * Image 01 : https://i.imgur.com/63SzWOq.png * Sorry, I couldn't test on the official version because I don't have my premium subscription anymore, so I can't add attachments.
OVERLORD added the low prioritytroubleshootingbug labels 2025-10-09 17:03:55 +03:00
Author
Owner

@Nyxtorm commented on GitHub:

It is indeed only the desktop client (Windows for my part) that allows to follow these steps, I forgot to specify it.

The web client and browser addons have a completely separate interface for managing attachments.

So I can guess that this is only a problem with the Windows client itself which should also have a "separate" attachments management?

@Nyxtorm commented on GitHub: It is indeed only the desktop client (Windows for my part) that allows to follow these steps, I forgot to specify it. The web client and browser addons have a completely separate interface for managing attachments. So I can guess that this is only a problem with the Windows client itself which should also have a "separate" attachments management?
Author
Owner

@BlackDex commented on GitHub:

I'm a bit puzzled here since within the web-vault you can't edit both the attachments and other parts of that same item simultaneously. They both have different interfaces.

If you have two browsers open, or use two different clients, then this is expected behavior since you would overwrite a newer version from an older version in the cache of the other client.

If you could explain a bit better which exact steps you take with which clients then maybe we can figure out what's going on.

@BlackDex commented on GitHub: I'm a bit puzzled here since within the web-vault you can't edit both the attachments and other parts of that same item simultaneously. They both have different interfaces. If you have two browsers open, or use two different clients, then this is expected behavior since you would overwrite a newer version from an older version in the cache of the other client. If you could explain a bit better which exact steps you take with which clients then maybe we can figure out what's going on.
Author
Owner

@BlackDex commented on GitHub:

I did a bit more digging, and it may also be an issue for the official bitwarden server, but it looks like both there self-hosted and the SAAS version do not implement the websockets correctly.

This in turn causes some code parts to not being triggered, and could in turn make it look like nothing is wrong.
I tested this by turning of websockets, and that seems to solve the issue when adding an attachment and updating the cipher afterwards.

Deleting an attachment still is an issue, that will cause an unknown attachment error. Which may be something we could catch in these cases maybe.

@BlackDex commented on GitHub: I did a bit more digging, and it may also be an issue for the official bitwarden server, but it looks like both there self-hosted and the SAAS version do not implement the websockets correctly. This in turn causes some code parts to not being triggered, and could in turn make it look like nothing is wrong. I tested this by turning of websockets, and that seems to solve the issue when adding an attachment and updating the cipher afterwards. Deleting an attachment still is an issue, that will cause an unknown attachment error. Which may be something we could catch in these cases maybe.
Author
Owner

@BlackDex commented on GitHub:

@Nyxtorm i had some time today to take a deeper dive into this issue.
And it looks like i fixed it. I can now add and delete attachments via the Desktop client without any errors.
I have to test this a bit more, and i also want to make some more changes in regards to the websocket notifications.

But, I'm working on it.
Basically, what happened was that due to how the websocket notifications were build, they were lacking the device-id from the client who executed the update. This triggered the Desktop client to also sync the cipher, and therefore was complaining about it being out-of-sync.

The clients check if the websocket notification is from them selfs by the device-id, and if so, it will stop processing.

@BlackDex commented on GitHub: @Nyxtorm i had some time today to take a deeper dive into this issue. And it looks like i fixed it. I can now add and delete attachments via the Desktop client without any errors. I have to test this a bit more, and i also want to make some more changes in regards to the websocket notifications. But, I'm working on it. Basically, what happened was that due to how the websocket notifications were build, they were lacking the device-id from the client who executed the update. This triggered the Desktop client to also sync the cipher, and therefore was complaining about it being out-of-sync. The clients check if the websocket notification is from them selfs by the device-id, and if so, it will stop processing.
Author
Owner

@BlackDex commented on GitHub:

I just tested this, and it indeed has an issue when using the deskop client.
If you add an attachment, then it will report that the cipher is outdated. If you remove an attachment it reports one of the attachments do not exists anymore.

This doesn't seem to be an issue the official Bitwarden server.

@BlackDex commented on GitHub: I just tested this, and it indeed has an issue when using the deskop client. If you add an attachment, then it will report that the cipher is outdated. If you remove an attachment it reports one of the attachments do not exists anymore. This doesn't seem to be an issue the official Bitwarden server.
Author
Owner

@Nyxtorm commented on GitHub:

@Nyxtorm i had some time today to take a deeper dive into this issue. And it looks like i fixed it. I can now add and delete attachments via the Desktop client without any errors. I have to test this a bit more, and i also want to make some more changes in regards to the websocket notifications.

But, I'm working on it. Basically, what happened was that due to how the websocket notifications were build, they were lacking the device-id from the client who executed the update. This triggered the Desktop client to also sync the cipher, and therefore was complaining about it being out-of-sync.

The clients check if the websocket notification is from them selfs by the device-id, and if so, it will stop processing.

@BlackDex, I was able to take the time to test and it's just perfect now, thanks again. 👍

@Nyxtorm commented on GitHub: > @Nyxtorm i had some time today to take a deeper dive into this issue. And it looks like i fixed it. I can now add and delete attachments via the Desktop client without any errors. I have to test this a bit more, and i also want to make some more changes in regards to the websocket notifications. > > But, I'm working on it. Basically, what happened was that due to how the websocket notifications were build, they were lacking the device-id from the client who executed the update. This triggered the Desktop client to also sync the cipher, and therefore was complaining about it being out-of-sync. > > The clients check if the websocket notification is from them selfs by the device-id, and if so, it will stop processing. @BlackDex, I was able to take the time to test and it's just perfect now, thanks again. 👍
Author
Owner

@BlackDex commented on GitHub:

Great, good to see it is resolved.

@BlackDex commented on GitHub: Great, good to see it is resolved.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#1104