Deta CLI and Deta Base: State Consistency During Build Reverts

Direct Answer

A Deta CLI build revert redeploys an older compute version, but it does not restore Deta Base to an earlier state. Items written or partially migrated by the failed build remain in the database. Reverting the build alone is therefore not sufficient to guarantee that the stable legacy code can read and write the existing data safely.

Likely Explanation vs. Confirmed Facts

Likely explanation

The failed deployment ran migration logic against Deta Base and updated some items before failing. This leaves items in mixed old and new schema shapes. When the previous stable build is redeployed, its read paths may encounter unexpected fields or missing fields and return errors or incorrect results.

Confirmed facts

• Build reverts affect the compute layer only.
• Deta Base persists independently of application builds.
• No automatic per-build data snapshot or rollback is confirmed for Deta Base.

Steps for This Case

1. Pause new writes that depend on the migrated schema using a feature flag or maintenance mode.
2. Query Deta Base for items carrying the new schema marker, such as a version field or new attribute, to identify partially migrated records.
3. Run an idempotent repair script that converts affected items back to the schema expected by the stable build. Use conditional updates so the script can be rerun safely.
4. Deploy the stable build to a review or stage Space pointed at a copy of the production Base. Exercise read and write paths against both pre-migration and post-migration item shapes.
5. Remove temporary fields or perform destructive cleanup only after the stable build is confirmed stable in production.

Missing Diagnostic Detail

Does your Deta Space account or plan currently offer Deta Base export, backup, or point-in-time restore? This determines whether you can restore data instead of repairing it in place. If restore is unavailable, proceed with the repair script above.

Verification

• In the Deta Space CLI or console, list the backup or export options for your Deta Base instance and confirm whether restore to a prior point is available.
• Check whether the migration script used conditional or idempotent writes and identify any partially updated items before repairing them.

Assumptions and Uncertainty

This assumes you can run queries and updates against Deta Base from the CLI or a one-off script. Treat per-build snapshots as unavailable unless confirmed in your current Deta Space console. Deta product availability and APIs have changed, so verify that Base backup and restore are still offered for your Space before planning a restore path.