How Laboratory Checkpoints Are Created in Restartable Batches

Laboratory checkpoint creation is batched and persisted so large sites can protect the lab without requiring one oversized PHP request.

Restartable design

QCUL stores the current checkpoint stage/cursor/progress and advances database/file work in bounded AJAX requests. Closing the browser pauses after the current request; reopening can continue from the saved cursor.

What you see

The laboratory status can show Saving lab restore point while database/file checkpoint phases are active. Progress may be uneven because database tables and files differ in size and cost.

Do not skip a failed checkpoint

If checkpoint creation fails, read the storage/database/permission error and correct it. Installing the update without a valid pre-test restore point would undermine the Undo Lab Update contract.

Preserve a known starting state

How Laboratory Checkpoints Are Created in Restartable Batches is useful only when the restore point and current laboratory belong to the same latest test operation. If you cannot prove that relationship, refresh the laboratory from current production and perform a new test rather than manually reconstructing a state and reusing old evidence.

Community Discussion

Want to compare update-testing workflows, share practical tips, or discuss how you use this QCUL feature? Visit the QC Update Laboratory Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.