Lightning updates triggering full rebakes

[mlbrgl]

Description

Lightning updates are currently triggering full rebakes.

Expected behaviour

Lightning updates should trigger partial/lightning rebakes. They are correctly identified on the front-end (see ⚡️ icon in "Republish button), but the check seems to fail on the backend.

Steps to reproduce

Steps to reproduce the behavior:

1. Create a test Gdoc and publish it
2. Change its content only
3. Confirm there is a ⚡️ in the Republish button
4. ⚡️ Republish
5. Check the content of .queue (or .pending depending on how fast you are)

The "slug" key - a marker of a lightning deploy - is missing, e.g.:

{"timeISOString":"2024-01-17T14:26:58.166Z","authorName":"Admin User","authorEmail":"admin@example.com","message":"Updating test-article"}

[ikesau]

Probably something wrong in checkIsLightningUpdate with a Date/string coercion problem.

This time when we fix it, create unit tests to make it easier to catch if/when it breaks again.

[rakyi]

We tested that the lightning updates get correctly put in the queue file. Needs to check that this bakes atomically.

[rakyi]

I also verified this works on staging, but only sometimes. 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.

[rakyi]

Closing this since we confirmed lightning updates don't trigger full rebakes. Opened #3908 for the new issue.