Potential inconsistances with propagation outside of transaction

[GeoffreyHuck]

Creating this issue to address this potential problem

Originally posted by @zenovich in #1099 (comment)

          **The main thing:**

If we schedule a propagation outside of a transaction, we cannot guarantee that data modifications already committed to the DB will be followed by a corresponding scheduled propagation. Indeed, let's consider a situation where, for instance, an AWS Lamba function processing a user request gets killed because of a timeout right after it has committed the data modifications to the DB, but before it has called another AWS Lambda function to trigger the propagation.

Such situations are really dangerous and hard to debug. They will definitely lead to production failures and DB inconsistency issues.

I would think 100500 times before doing this and finally would find another approach.

[GeoffreyHuck]

@zenovich in your example:

1. The propagation is run outside the transaction, but the transaction itself commits the data updates as well as the markers required for the propagation to put the database in a consistent state again.
2. The DB is only in a temporary inconsistent state that will be corrected once the propagation is run again.

Are those correct? If yes, I think we can close the issue. If not, please tell me why.

[zenovich]

The DB is only in a temporary inconsistent state that will be corrected once the propagation is run again.

This "temporary inconsistent state" can be very dangerous.

[zenovich]

like here: #1149