You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When lightning update bakes a single GDoc, it sometimes doesn't update the content.
Expected behaviour
Lightning update should always result in updated content.
Steps to reproduce
Steps to reproduce the behavior:
Publish a new GDoc
While the change is deploying, update its body
Click Republish button in its admin (it should have a lightning icon) and confirm the change
There should be two changes in the deploy queue in admin:
Full deploy triggerend by the publication of the article
Lightning update of the article
Check the content of the article after both changes complete - it should have the original content before update
Environment
Staging server
Additional context
AFAICT, the problem seems to be that we update the GDoc and enqueue the update in the same DB transaction, which creates a race condition.
If the deploy-queue process reads the change from the file system and starts its own transaction before the previous one commits, it will bake the GDoc with the old content. In my testing, it worked when the lighting update was the only change in the queue, but it failed when it was enqueued after a full bake that was in progress. Not sure if this makes a difference.
On prod, we trigger the bake in Buildkite instead of running it on the deploy-queue process, which is another code path I didn't verify, but presumably the race condition would be much less likely there.
The text was updated successfully, but these errors were encountered:
Description
When lightning update bakes a single GDoc, it sometimes doesn't update the content.
Expected behaviour
Lightning update should always result in updated content.
Steps to reproduce
Steps to reproduce the behavior:
Environment
Staging server
Additional context
AFAICT, the problem seems to be that we update the GDoc and enqueue the update in the same DB transaction, which creates a race condition.
If the deploy-queue process reads the change from the file system and starts its own transaction before the previous one commits, it will bake the GDoc with the old content. In my testing, it worked when the lighting update was the only change in the queue, but it failed when it was enqueued after a full bake that was in progress. Not sure if this makes a difference.
On prod, we trigger the bake in Buildkite instead of running it on the deploy-queue process, which is another code path I didn't verify, but presumably the race condition would be much less likely there.
The text was updated successfully, but these errors were encountered: