This PR avoids a potential issue on GCP whereby a checkpoint can be out of date with respect to the log's internal state.
Writes to GCS are rate-limited per object, it's possible that a write to checkpoint can be rejected if this limit triggers. If that happens on the final integration run which completely drains the sequenced items in Spanner, then the GCS checkpoint file won't be updated again until new entries are sequenced.
This PR resolves this by simply aborting the integrate run if checkpoint is not successfully written (along with any other GCS resources). This means that the whole integration will be retried at the next attempt, which will likely incur the "idempotency" checks on the GCS resources, but it should happen rarely enough that this isn't overly burdensome.
This PR avoids a potential issue on GCP whereby a checkpoint can be out of date with respect to the log's internal state.
Writes to GCS are rate-limited per object, it's possible that a write to
checkpointcan be rejected if this limit triggers. If that happens on the final integration run which completely drains the sequenced items in Spanner, then the GCS checkpoint file won't be updated again until new entries are sequenced.This PR resolves this by simply aborting the integrate run if
checkpointis not successfully written (along with any other GCS resources). This means that the whole integration will be retried at the next attempt, which will likely incur the "idempotency" checks on the GCS resources, but it should happen rarely enough that this isn't overly burdensome.We can revisit later if necessary.
23