[SebastianKrupinski]

Summary

• Resolves: # Client Ticket
• remove the per-card atomic() wrapper in SyncService::syncRemoteAddressBook(). getCard + createCard/updateCard are already atomic individually.
• remove the atomic() wrapper in SyncService::updateUser().
• Also call createCardFromUser() only once, before any DB work. It's currently called inside the transaction on both branches, and it's the slow part (avatar and account data).

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[SebastianKrupinski]

/backport to stable35

[SebastianKrupinski]

/backport to stable34

[SebastianKrupinski]

/backport to stable33

[tcitworld]

Why would these be long-running transactions since only one card is updated at a time ?

[SebastianKrupinski]

Why would these be long-running transactions since only one card is updated at a time ?

Sorry, I used the wrong wording! The issue is nesting, I am working to improving how long the sync takes also and mixed the two up

The nested transactions case a dead lock error:

An exception occurred while executing a query: SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT DOCTRINE_2 does not exist

As createCard(), updateCard() and deleteCard() each open their own atomic() there is no point in wrapping them in another transaction

[tcitworld]

As createCard(), updateCard() and deleteCard() each open their own atomic() there is no point in wrapping them in another transaction

Well, the need was read-after-write kind of issue, but there's very low risk in these cases, and no way to avoid your issue anyway.