2007337 - Thunderbird hangs when syncing carddav address book with sync token for up to 30 minutes

Status: UNCONFIRMED

(Thunderbird :: Address Book, defect, P2)

Description

[mt_]

Steps to reproduce:

What is the issue?

Thunderbird hangs in a certain situation when syncing carddav address books with a sync token. Every time the server replies with a lot of contacts this way, Thunderbird hangs while processing the reply. This behavior can be reproduced at will with Thunderbird 32bit ESR 140.0.1 to 140.6.0 - other versions (non-ESR, 64bit, older / perhaps newer) haven't been tested yet.

How to reproduce

• Windows 11 Enterprise, 64bit, newest updates
• Thunderbird 140.X ESR (140.0.1 up to 140.6.0 tested), 32bit
• CardDAV address book (openxchange middleware) with >15.000 contacts
• added said address book to thunderbird
• address book NOT fully synced
• initial sync without issue, thunderbird however only receives first 1.000 contacts
• reset sync-token to an older value (UNIX-Time, e.g. -1 Hour)

Actual results:

After the REPORT-Request sent to the CardDAV server with a sync-token is returned (return size 11MB), Thunderbird starts to hang. ProcMon reveals that millions of read entries are being done to the abook.sqlite file. On my developer-machine it takes about 2-3 minutes until the issue is resolved and thunderbird works again, on our customer PCs with far less computing power it takes up to 30 minutes.

Expected results:

Thunderbird shouldn't hang at all, obviously.
It doesn't hang when removing the sync token from the configuration (ldap_X.servers.AddressBook.carddav.token), however every sync request from then on out would result in the server replying with the whole address book, which is something we can't afford due to our infrastructure (roughly 40.000 users hosted on openxchange).

Comment 1

[mt_]

Profiler log (certain domain names and account names redacted due to privacy reasons): https://share.firefox.dev/4p7Q8mn

Comment 2

[Geoff Lankow (:darktrojan)]

According to the performance profile, it's the address book UI that's struggling to handle so many contacts being added at once.

What happens if the sync happens while the address book tab is not open? E.g. if the periodic sync happens automatically, or if you trigger synchronisation then immediately close the tab?

Comment 3

[Geoff Lankow (:darktrojan)]

I also think we're probably doing something wrong if only the first 1000 contacts are added initially. I'll see if I can reproduce that.

Comment 4

[mt_]

(In reply to Geoff Lankow (:darktrojan) from comment #2)

According to the performance profile, it's the address book UI that's struggling to handle so many contacts being added at once.

What happens if the sync happens while the address book tab is not open? E.g. if the periodic sync happens automatically, or if you trigger synchronisation then immediately close the tab?

It also happens when not having the address book tab open.
I've gathered a profiler log of the issue while the adress book tab is closed (reset sync token to an older timestamp, start sync, close adress book tab, wait): https://share.firefox.dev/4pVmVvz

Comment 5

[Geoff Lankow (:darktrojan)]

Hmm, I'd overlooked that there were two expensive operations going on. I've got the worse one under control in bug 2009264. The other should be fairly easy to fix too. Thanks for investigating.

Comment 6

[Geoff Lankow (:darktrojan)]

If possible, I'd like to see what's in the initial propfind HTTP response that returns 1000 contacts. Could you grab that for me, using the developer tools network tab? I probably only need the first <response> section, after that I expect there'll be 1000 more <response>s, one for each contact.

I haven't been able to make any server I have access to limit the list, and the CardDAV spec isn't really clear on what's supposed to happen.

Comment 7

[hexmasteen]

most likely related/duplicate: bug 2005528

Comment 9

[mt_]

Attachment: openxchange-tb-carddav-sync-only-1000-at-a-time.har

HAR file of propfinds and reports of a sample carddav address book with 19027 entries

Comment 10

[mt_]

(In reply to Geoff Lankow (:darktrojan) from comment #6)

If possible, I'd like to see what's in the initial propfind HTTP response that returns 1000 contacts. Could you grab that for me, using the developer tools network tab? I probably only need the first <response> section, after that I expect there'll be 1000 more <response>s, one for each contact.

I haven't been able to make any server I have access to limit the list, and the CardDAV spec isn't really clear on what's supposed to happen.
Sure, I've attached openxchange-tb-carddav-sync-only-1000-at-a-time.har to the bug (redacted where it was needed).

Server: OpenXChange
Sample entries in address book: 19027

1. TB requests all entries from the server
2. Server responds with all .vcf-files and
3. TB requests the content of all the .vcf-files
4. Server responds the first 1000 entries, then returns HTTP/1.1 507 Insufficient Storage
5. TB does another propfind request requesting the displayname and sync-token
6. Server returns the sync token: 1768501622161.0.19027

The 507 error suggests it's actually related to OpenXchange itself, not Thunderbird.
We also have a QS environment for OpenXchange, where we deployed an update yesterday with the changelog having "address book limit increased" in it. I just tested the same setup in said QS and got all 19027 contacts in one go - slow, as all contacts were returned by the server, but Thunderbird was responsive the whole time (140.6.0esr).

So this "only 1000 contacts being synced" issue might not be an issue with Thunderbird after all!

We're in close contact with the OpenXchange devs, I'll reach out to them to figure out if the deployed update fixed something amongst the lines of only 1000 contacts synced at a time. I'll update you once I get a reply!

Comment 11

[Geoff Lankow (:darktrojan)]

Wow, uh, okay, I was half expecting to see 507 errors, but not there! That is the error code mentioned in the spec although it's vague on where it's supposed to be used and for what reasons.

Even if it is an OpenXchange problem, I think maybe Thunderbird should not request all of the contacts in one go, but in batches. We do something similar in CalDAV but that approach has other problems. I'll do some experimentation next week.

Thanks for the info.