[GH-ISSUE #4719 ] When using vaultwarden version 1.31.0 and the beta version of bitwarden, synchronization fails. #1966

Author

Owner

@BlackDex commented on GitHub (Jul 10, 2024):

There seems to be nothing wrong with this single cipher looking at it quickly.

@BlackDex commented on GitHub (Jul 10, 2024): There seems to be nothing wrong with this single cipher looking at it quickly.

kerem commented

Author

Owner

@cobyge commented on GitHub (Jul 10, 2024):

Another thing:
In collections, there is a field called manage that I only see in Bitwarden but not in Vaultwarden:

"collections": [
    {
        "readOnly": false,
        "hidePasswords": false,
        "manage": true,
        "id": "{REDACTO_MAGICO}",
        "organizationId": "{REDACTO_MAGICO}",
        "name": "{REDACTO_MAGICO}",
        "externalId": null,
        "object": "collectionDetails"
    }
],

If that still isn't it, then let me know how I can contact you privately and send you a copy of my /api/sync results.

@cobyge commented on GitHub (Jul 10, 2024): Another thing: In `collections`, there is a field called `manage` that I only see in Bitwarden but not in Vaultwarden: ```json "collections": [ { "readOnly": false, "hidePasswords": false, "manage": true, "id": "{REDACTO_MAGICO}", "organizationId": "{REDACTO_MAGICO}", "name": "{REDACTO_MAGICO}", "externalId": null, "object": "collectionDetails" } ], ``` If that still isn't it, then let me know how I can contact you privately and send you a copy of my `/api/sync` results.

kerem commented

Author

Owner

@BlackDex commented on GitHub (Jul 10, 2024):

I do not have manage either, and that works fine.
It must be something in the ciphers, or maybe sends.

All other items are not dynamic or different between other servers.

@BlackDex commented on GitHub (Jul 10, 2024): I do not have manage either, and that works fine. It must be something in the ciphers, or maybe sends. All other items are not dynamic or different between other servers.

kerem commented

Author

Owner

@BlackDex commented on GitHub (Jul 10, 2024):

I did some more testing with adding the "response" to a my test setup. But that doesn't seem to break it at all.
So it must be something else, something not yet posted.

@BlackDex commented on GitHub (Jul 10, 2024): I did some more testing with adding the `"response"` to a my test setup. But that doesn't seem to break it at all. So it must be something else, something not yet posted.

kerem commented

Author

Owner

@cobyge commented on GitHub (Jul 10, 2024):

Managed to catch the bug:

kotlinx.serialization.MissingFieldException: Field 'type' is required for type with serial name 'com.x8bit.bitwarden.data.vault.datasource.network.model.SyncResponseJson.Cipher.SecureNote', but it was missing at path: $.ciphers[172].secureNote

@cobyge commented on GitHub (Jul 10, 2024): Managed to catch the bug: ``` kotlinx.serialization.MissingFieldException: Field 'type' is required for type with serial name 'com.x8bit.bitwarden.data.vault.datasource.network.model.SyncResponseJson.Cipher.SecureNote', but it was missing at path: $.ciphers[172].secureNote ```

kerem commented

Author

Owner

@cobyge commented on GitHub (Jul 10, 2024):

For some reason I have two entries which contain:
"secureNote": {}

@cobyge commented on GitHub (Jul 10, 2024): For some reason I have two entries which contain: `"secureNote": {}`

kerem commented

Author

Owner

@cobyge commented on GitHub (Jul 10, 2024):

Which is weird, as #4685 should have fixed this

@cobyge commented on GitHub (Jul 10, 2024): Which is weird, as #4685 should have fixed this

kerem commented

Author

Owner

@BlackDex commented on GitHub (Jul 10, 2024):

Well, not exactly.

Do you mean this part?

    "name": "{REDACTO_MAGICO}",
    "notes": null,
    "object": "cipherDetails",
    "organizationId": null,
    "organizationUseTotp": true,
    "passwordHistory": [],
    "revisionDate": "{REDACTO_MAGICO}",
    "secureNote": {}, <------- It shows {} instead of null?
    "type": 1,
    "viewPassword": true
}

@BlackDex commented on GitHub (Jul 10, 2024): Well, not exactly. Do you mean this part? ```json "name": "{REDACTO_MAGICO}", "notes": null, "object": "cipherDetails", "organizationId": null, "organizationUseTotp": true, "passwordHistory": [], "revisionDate": "{REDACTO_MAGICO}", "secureNote": {}, <------- It shows {} instead of null? "type": 1, "viewPassword": true } ```

kerem commented

Author

Owner

@BlackDex commented on GitHub (Jul 10, 2024):

Could you check your database for those ciphers and provide what is listed in the data column?

@BlackDex commented on GitHub (Jul 10, 2024): Could you check your database for those ciphers and provide what is listed in the `data` column?

kerem commented

Author

Owner

@cobyge commented on GitHub (Jul 10, 2024):

There is an empty string for some reason.
That means that here

if self.atype == 2 && (self.data.eq("{}") || self.data.to_ascii_lowercase().eq("{\"type\":null}")) {

In that case self.data is an empty string instead of {}
I added

if self.atype == 2 {
    println!("Self.data, {:?}", self.data);
}

Above the previous line in order to verify the output, and there are 2 lines of:

Self.data, ""

I assume that is whats causing the issue, as earlier on in the code the default serialized value is set as {}

// Get the type_data or a default to an empty json object '{}'.
// If not passing an empty object, mobile clients will crash.
let mut type_data_json = serde_json::from_str::<LowerCase<Value>>(&self.data)
    .map(|d| d.data)
    .unwrap_or_else(|_| Value::Object(serde_json::Map::new()));

@cobyge commented on GitHub (Jul 10, 2024): There is an empty string for some reason. That means that [here](https://github.com/dani-garcia/vaultwarden/blob/main/src/db/models/cipher.rs#L194) ```rust if self.atype == 2 && (self.data.eq("{}") || self.data.to_ascii_lowercase().eq("{\"type\":null}")) { ``` In that case self.data is an empty string instead of `{}` I added ```rust if self.atype == 2 { println!("Self.data, {:?}", self.data); } ``` Above the previous line in order to verify the output, and there are 2 lines of: ```rust Self.data, "" ``` I assume that is whats causing the issue, as earlier on in the [code](https://github.com/dani-garcia/vaultwarden/blob/6fedfceaa9d43f14a4c65695a42b42b095659b42/src/db/models/cipher.rs#L176) the default serialized value is set as `{}` ```rust // Get the type_data or a default to an empty json object '{}'. // If not passing an empty object, mobile clients will crash. let mut type_data_json = serde_json::from_str::<LowerCase<Value>>(&self.data) .map(|d| d.data) .unwrap_or_else(|_| Value::Object(serde_json::Map::new())); ```

kerem commented

Author

Owner

@cobyge commented on GitHub (Jul 10, 2024):

I can confirm that changing the code to:

if self.atype == 2 && (self.data.eq("{}") || self.data.is_empty() || self.data.to_ascii_lowercase().eq("{\"type\":null}")) {

(Adding self.data.is_empty())
fixes the issue

@cobyge commented on GitHub (Jul 10, 2024): I can confirm that changing the code to: ```rust if self.atype == 2 && (self.data.eq("{}") || self.data.is_empty() || self.data.to_ascii_lowercase().eq("{\"type\":null}")) { ``` (Adding `self.data.is_empty()`) fixes the issue

kerem commented

Author

Owner

@BlackDex commented on GitHub (Jul 10, 2024):

Ah! Your's is empyt? That isn't something i encountered before.

@BlackDex commented on GitHub (Jul 10, 2024): Ah! Your's is empyt? That isn't something i encountered before.

kerem commented

Author

Owner

@BlackDex commented on GitHub (Jul 10, 2024):

If you wan't you can make a PR for this.

@BlackDex commented on GitHub (Jul 10, 2024): If you wan't you can make a PR for this.

kerem commented

Author

Owner

@wanlufun commented on GitHub (Jul 11, 2024):

It's probably the same as reported here: #4386 (comment)

There probably is something inside your data column in the ciphers table which causes an issue. Since the new clients do not seem to report where it fails in a nice way it's hard to really pinpoint the specific problem it self.

For that we would need to see the output of the sync request and try to find the possible issue. I'm not sure if you are willing to provide us some of these details? All data is encrypted.

I'm sorry for not being able to assist in the past couple of days due to academic exams.

I see that this issue has been resolved, but I still cannot retrieve the sync data after repackaging the latest docker image.

So, I used a binary search method, deleting my password vault, and found a data item that was causing the import issue.

In this data item, I didn't fill in any notes, but the returned data still contained notes.

data item

{
  "attachments": null,
  "card": null,
  "collectionIds": [],
  "creationDate": "2024...........6433Z",
  "data": {
    "fido2Credentials": [],
    "fields": [],
    "name": "2.RuhHL.........U=",
    "notes": "2./p9SER........Vs=",
    "password": "2.uhkc.........VguwvE=",
    "passwordHistory": [],
    "passwordRevisionDate": "2024-..........274800Z",
    "totp": null,
    "uri": "2./zO...........CQH64=",
    "uris": [
      {
        "match": null,
        "uri": "2./zO..............QH64="
      }
    ],
    "username": "2.ye............Mg="
  },
  "deletedDate": null,
  "edit": true,
  "favorite": false,
  "fields": [],
  "folderId": null,
  "id": "2dff............a5934e",
  "identity": null,
  "key": null,
  "login": {
    "fido2Credentials": [],
    "password": "2.uhkc.....................u0VguwvE=",
    "passwordRevisionDate": "2024.............00Z",
    "totp": null,
    "uri": "2....................OCQH64=",
    "uris": [
      {
        "match": null,
        "uri": "2./z.......................POCQH64="
      }
    ],
    "username": "2.yeu...................T5WefMg="
  },
  "name": "2.Ruh................aQeYU=",
  "notes": "2./p9SER..................eBVs=",
  "object": "cipherDetails",
  "organizationId": null,
  "organizationUseTotp": true,
  "passwordHistory": [],
  "reprompt": 0,
  "revisionDate": "202...............6664Z",
  "secureNote": null,
  "type": 1,
  "viewPassword": true
}

@wanlufun commented on GitHub (Jul 11, 2024): > It's probably the same as reported here: [#4386 (comment)](https://github.com/dani-garcia/vaultwarden/pull/4386#issuecomment-2212324855) > > There probably is something inside your `data` column in the `ciphers` table which causes an issue. Since the new clients do not seem to report where it fails in a nice way it's hard to really pinpoint the specific problem it self. > > For that we would need to see the output of the `sync` request and try to find the possible issue. I'm not sure if you are willing to provide us some of these details? All data is encrypted. I'm sorry for not being able to assist in the past couple of days due to academic exams. I see that this issue has been resolved, but I still cannot retrieve the sync data after repackaging the latest docker image. So, I used a binary search method, deleting my password vault, and found a data item that was causing the import issue. In this data item, I didn't fill in any notes, but the returned data still contained notes. data item ```json { "attachments": null, "card": null, "collectionIds": [], "creationDate": "2024...........6433Z", "data": { "fido2Credentials": [], "fields": [], "name": "2.RuhHL.........U=", "notes": "2./p9SER........Vs=", "password": "2.uhkc.........VguwvE=", "passwordHistory": [], "passwordRevisionDate": "2024-..........274800Z", "totp": null, "uri": "2./zO...........CQH64=", "uris": [ { "match": null, "uri": "2./zO..............QH64=" } ], "username": "2.ye............Mg=" }, "deletedDate": null, "edit": true, "favorite": false, "fields": [], "folderId": null, "id": "2dff............a5934e", "identity": null, "key": null, "login": { "fido2Credentials": [], "password": "2.uhkc.....................u0VguwvE=", "passwordRevisionDate": "2024.............00Z", "totp": null, "uri": "2....................OCQH64=", "uris": [ { "match": null, "uri": "2./z.......................POCQH64=" } ], "username": "2.yeu...................T5WefMg=" }, "name": "2.Ruh................aQeYU=", "notes": "2./p9SER..................eBVs=", "object": "cipherDetails", "organizationId": null, "organizationUseTotp": true, "passwordHistory": [], "reprompt": 0, "revisionDate": "202...............6664Z", "secureNote": null, "type": 1, "viewPassword": true } ````

kerem commented

Author

Owner

@wanlufun commented on GitHub (Jul 11, 2024):

When I re-added and then deleted the notes for this data item, and then updated it, Bitwarden Android Beta worked normally. I don't quite remember how I saved this data item (browser extension, manual, keyguard). It seems that the issue might be with those methods (browser extension, manual, keyguard).

@wanlufun commented on GitHub (Jul 11, 2024): When I re-added and then deleted the notes for this data item, and then updated it, Bitwarden Android Beta worked normally. I don't quite remember how I saved this data item (browser extension, manual, keyguard). It seems that the issue might be with those methods (browser extension, manual, keyguard).

kerem commented

Author

Owner

@BlackDex commented on GitHub (Jul 11, 2024):

Id you have a backup of your database before you made the changes, could you test it with the latest testing tagged image and see if that solves it without any modifications on your side?

@BlackDex commented on GitHub (Jul 11, 2024): Id you have a backup of your database before you made the changes, could you test it with the latest `testing` tagged image and see if that solves it without any modifications on your side?

kerem commented

Author

Owner

@wanlufun commented on GitHub (Jul 11, 2024):

Oh, there is a testing image? That's great!

I restored the database backup and used the testing image. Without any modifications, the mobile client couldn't sync properly. Then I modified the notes for all data items through the web vault interface (which should be equivalent to resetting the validity of the notes data), and it returned to normal.

@wanlufun commented on GitHub (Jul 11, 2024): Oh, there is a testing image? That's great! I restored the database backup and used the testing image. Without any modifications, the mobile client couldn't sync properly. Then I modified the notes for all data items through the web vault interface (which should be equivalent to resetting the validity of the notes data), and it returned to normal.

kerem commented

Author

Owner

@BlackDex commented on GitHub (Jul 11, 2024):

I would love to know what the difference is before and after.
Could you provide this?

@BlackDex commented on GitHub (Jul 11, 2024): I would love to know what the difference is before and after. Could you provide this?

kerem commented

Author

Owner

@wanlufun commented on GitHub (Jul 12, 2024):

yes, i can provide.

For example:
I found a problematic data item.

I checked this data item through the web vault, and in this data item, the notes field was empty.

However, when I checked the return value of the sync, the notes field in this data item had a value (which theoretically should be null).

Then, I added content to the empty notes field in the web vault and save (meaning I updated the notes field of this data item).

I checked the return value of /api/ciphers/, and at this point, the content of the notes field had changed.

Then, I logged in to the client, and it was able to sync normally.

I suspect that the notes in the original data item could not be decrypted properly, causing the client to fail to parse the data, which then led to the error. The cause of this issue might be some third-party software. Currently, I am using Keyguard, but I haven't tested it yet.

@wanlufun commented on GitHub (Jul 12, 2024): yes, i can provide. For example: I found a problematic data item. I checked this data item through the web vault, and in this data item, the notes field was empty. ![image](https://github.com/user-attachments/assets/9f32ab7b-96cb-44d3-b463-6b0577f8485f) However, when I checked the return value of the sync, the notes field in this data item had a value (which theoretically should be null). ![image](https://github.com/user-attachments/assets/6be8fde8-9dcb-4779-8e39-e9e7bffa98fd) Then, I added content to the empty notes field in the web vault and save (meaning I updated the notes field of this data item). ![image](https://github.com/user-attachments/assets/b9d00235-8c14-43f3-b931-ff1541991db3) I checked the return value of /api/ciphers/<id>, and at this point, the content of the notes field had changed. ![image](https://github.com/user-attachments/assets/deac116f-8309-469c-8193-9cd8a1e8dd63) Then, I logged in to the client, and it was able to sync normally. I suspect that the notes in the original data item could not be decrypted properly, causing the client to fail to parse the data, which then led to the error. The cause of this issue might be some third-party software. Currently, I am using Keyguard, but I haven't tested it yet.

kerem commented

Author

Owner

@wanlufun commented on GitHub (Jul 12, 2024):

I think the official client seems to encounter an error when it cannot properly parse some data in a data item.

I believe it would be beneficial to submit an issue to the official client, suggesting that it should display the normal data items and ignore the abnormal ones while notifying the user. I wonder if the web vault should also handle it this way. I haven't seen any parse errors thrown in the console.

@wanlufun commented on GitHub (Jul 12, 2024): I think the official client seems to encounter an error when it cannot properly parse some data in a data item. I believe it would be beneficial to submit an issue to the official client, suggesting that it should display the normal data items and ignore the abnormal ones while notifying the user. I wonder if the web vault should also handle it this way. I haven't seen any parse errors thrown in the console.

kerem commented

Author

Owner

@BlackDex commented on GitHub (Jul 12, 2024):

@wanlufun, i noticed that in the screenshot where you say it fails, it is still using PascalCase key names, like Notes, and in the screenshot you show where it is working, it is using camelCase, like notes.

The latter is the version which should be working on the new beta clients, since those clients to do not understand Notes, but only notes. But this is the same for all other items btw, which also show capital case first letters.

Are you sure you used the v1.31.0 (or the latest testing version) during that test?

@BlackDex commented on GitHub (Jul 12, 2024): @wanlufun, i noticed that in the screenshot where you say it fails, it is still using PascalCase key names, like `Notes`, and in the screenshot you show where it is working, it is using camelCase, like `notes`. The latter is the version which should be working on the new beta clients, since those clients to do not understand `Notes`, but only `notes`. But this is the same for all other items btw, which also show capital case first letters. Are you sure you used the v1.31.0 (or the latest testing version) during that test?

kerem commented

Author

Owner

@wanlufun commented on GitHub (Jul 12, 2024):

@BlackDex, Due to my oversight, I compared two versions and posted the wrong image. In the above response, the two images are from different versions.

Here is the correct image for Chapter One.

@wanlufun commented on GitHub (Jul 12, 2024): @BlackDex, Due to my oversight, I compared two versions and posted the wrong image. In the above response, the two images are from different versions. Here is the correct image for Chapter One. ![image](https://github.com/user-attachments/assets/03abda1a-87d0-4ae8-ae9c-81e761495eac)

kerem commented

Author

Owner

@BlackDex commented on GitHub (Jul 12, 2024):

Strange indeed. I do not see anything strange here. And since you can resolve it by hosting the cipher, and the layout/keys are not different, i think it's not something we can fix on our side.

In that case, I'm going to close this again.

@BlackDex commented on GitHub (Jul 12, 2024): Strange indeed. I do not see anything strange here. And since you can resolve it by hosting the cipher, and the layout/keys are not different, i think it's not something we can fix on our side. In that case, I'm going to close this again.

kerem commented

Author

Owner

@a15355447898a commented on GitHub (Nov 21, 2024):

I have the same issue. I'm using the vaultwarden 1.32.5 docker image.
My Bitwarden desktop clients on Windows and Linux, as well as the beta version of the browser extension, work fine.
However, on my Android phone, the Bitwarden beta version 2024.11.5 (19461) (latest version) displays "We were unable to process your request. Please try again or contact us."
On the same phone, the third-party client "keyguard" works normally.
I am not very skilled in programming-related techniques. Can you tell me how to troubleshoot this issue? I'd be happy to provide any related error logs.

When clicking sync on the problematic Bitwarden client, the vaultwarden logs are as follows:

[2024-11-21 02:52:10.234][response][INFO] (sync) GET /api/sync?<data..> => 200 OK
[2024-11-21 02:52:09.770][request][INFO] GET /api/sync
[2024-11-21 02:52:09.724][response][INFO] (revision_date) GET /api/accounts/revision-date => 200 OK
[2024-11-21 02:52:09.684][request][INFO] GET /api/accounts/revision-date

I don't know how to view the error logs of the Android client; I'm sorry I can't provide them.

@a15355447898a commented on GitHub (Nov 21, 2024): I have the same issue. I'm using the vaultwarden 1.32.5 docker image. My Bitwarden desktop clients on Windows and Linux, as well as the beta version of the browser extension, work fine. However, on my Android phone, the Bitwarden beta version 2024.11.5 (19461) (latest version) displays "We were unable to process your request. Please try again or contact us." On the same phone, the third-party client "keyguard" works normally. I am not very skilled in programming-related techniques. Can you tell me how to troubleshoot this issue? I'd be happy to provide any related error logs. When clicking sync on the problematic Bitwarden client, the vaultwarden logs are as follows: ``` [2024-11-21 02:52:10.234][response][INFO] (sync) GET /api/sync?<data..> => 200 OK [2024-11-21 02:52:09.770][request][INFO] GET /api/sync [2024-11-21 02:52:09.724][response][INFO] (revision_date) GET /api/accounts/revision-date => 200 OK [2024-11-21 02:52:09.684][request][INFO] GET /api/accounts/revision-date ``` I don't know how to view the error logs of the Android client; I'm sorry I can't provide them.

kerem commented

Author

Owner

@wanlufun commented on GitHub (Nov 21, 2024):

@a15355447898a

You can try accessing the Vaultwarden web interface and editing the notes field for all your items, regardless of whether they currently contain any content. After making these changes, try logging into the beta version of the Bitwarden app on your phone and testing it again. During this process, avoid using the Keyguard client to ensure accurate results.

Let me know if this helps resolve the issue!

@wanlufun commented on GitHub (Nov 21, 2024): @a15355447898a You can try accessing the Vaultwarden web interface and editing the notes field for all your items, regardless of whether they currently contain any content. After making these changes, try logging into the beta version of the Bitwarden app on your phone and testing it again. During this process, avoid using the Keyguard client to ensure accurate results. Let me know if this helps resolve the issue!

kerem commented

Author

Owner

@a15355447898a commented on GitHub (Nov 21, 2024):

@a15355447898a

You can try accessing the Vaultwarden web interface and editing the notes field for all your items, regardless of whether they currently contain any content. After making these changes, try logging into the beta version of the Bitwarden app on your phone and testing it again. During this process, avoid using the Keyguard client to ensure accurate results.

Let me know if this helps resolve the issue!

I have over 700 items in my Vaultwarden library, and it's impractical to modify them one by one. I tried the following methods:

First, I exported the password vault as JSON. I noticed that some of the notes fields looked like this: "notes": "", when they should normally be "notes": null,
I modified these items on the Vaultwarden web interface, and now the exported JSON only contains "notes": null, and "notes": "xxxxx",
Then I tried to log in using the Bitwarden Android beta client, but it still shows "We were unable to process your request. Please try again or contact us."
I created a new Vaultwarden on a different computer, imported the JSON exported from step two, and now the Android beta client can log in and function normally.

I don't know which step was effective, but it seems there are some issues with the Vaultwarden on the first computer.

@a15355447898a commented on GitHub (Nov 21, 2024): > @a15355447898a > > You can try accessing the Vaultwarden web interface and editing the notes field for all your items, regardless of whether they currently contain any content. After making these changes, try logging into the beta version of the Bitwarden app on your phone and testing it again. During this process, avoid using the Keyguard client to ensure accurate results. > > Let me know if this helps resolve the issue! I have over 700 items in my Vaultwarden library, and it's impractical to modify them one by one. I tried the following methods: * First, I exported the password vault as JSON. I noticed that some of the `notes` fields looked like this: `"notes": "",` when they should normally be `"notes": null,` * I modified these items on the Vaultwarden web interface, and now the exported JSON only contains `"notes": null,` and `"notes": "xxxxx",` * Then I tried to log in using the Bitwarden Android beta client, but it still shows "We were unable to process your request. Please try again or contact us." * I created a new Vaultwarden on a different computer, imported the JSON exported from step two, and now the Android beta client can log in and function normally. I don't know which step was effective, but it seems there are some issues with the Vaultwarden on the first computer.

kerem commented

Author

Owner

@wanlufun commented on GitHub (Nov 21, 2024):

@a15355447898a
Hello, you might want to try exporting the data from the Vaultwarden instance created in step 4 and then compare it with the content of your original export from step 1.

This comparison could help identify any differences or issues with the original Vaultwarden instance. Let me know if you need assistance with this process!

@wanlufun commented on GitHub (Nov 21, 2024): @a15355447898a Hello, you might want to try exporting the data from the Vaultwarden instance created in step 4 and then compare it with the content of your original export from step 1. This comparison could help identify any differences or issues with the original Vaultwarden instance. Let me know if you need assistance with this process!

kerem commented

Author

Owner

@BlackDex commented on GitHub (Nov 21, 2024):

Are you 100% sure you are using the latest version?

You can also try to do a password change including key-rotation.
That might help as well without too much hassle.

@BlackDex commented on GitHub (Nov 21, 2024): Are you 100% sure you are using the latest version? You can also try to do a password change including key-rotation. That might help as well without too much hassle.

kerem commented

Author

Owner

@a15355447898a commented on GitHub (Nov 21, 2024):

@a15355447898a Hello, you might want to try exporting the data from the Vaultwarden instance created in step 4 and then compare it with the content of your original export from step 1.

This comparison could help identify any differences or issues with the original Vaultwarden instance. Let me know if you need assistance with this process!

I compared them, and aside from the difference between "notes": "" and "notes": null, some ID and timestamp discrepancies, the only difference is the presence of trailing empty lines in some notes.
Modifying these trailing empty lines didn't help.

@a15355447898a commented on GitHub (Nov 21, 2024): > @a15355447898a Hello, you might want to try exporting the data from the Vaultwarden instance created in step 4 and then compare it with the content of your original export from step 1. > > This comparison could help identify any differences or issues with the original Vaultwarden instance. Let me know if you need assistance with this process! I compared them, and aside from the difference between "notes": "" and "notes": null, some ID and timestamp discrepancies, the only difference is the presence of trailing empty lines in some notes. Modifying these trailing empty lines didn't help.

kerem commented