@Alicja Celigowska [C] Sorry for the delay in my response
Here’s a suggested workaround
Read A, Read B, and update B (but only if neither A nor B has been changed in the meantime).
If you look at Mongo DB which suffers from the same limitation, they recommend altering item A to basically lock it as part of the transaction: How To SELECT ... FOR UPDATE inside MongoDB Transactions | MongoDB
And you could do something similar in Cosmos DB. Using a Stored Procedure (where everything is executed inside a single transaction) you could:
• Update A on some dummy fields which will lock it for writing
• Read A
• Read B
• Update B
• When the Stored Proc Commits, all those operations will succeed, or all will fail and you’ll have to run it again.
I think this should work, however, I have not tested it yet.
Please refer Work with stored procedures, triggers, and UDFs in Azure Cosmos DB | Microsoft Learn and there’s always the option of using a relational database where you have a richer capability around multi-operation transactions.