Warm migration failed: Invalid `prisma.migrationJob.update()

[neilcolyn-jpg]

Good Day,

We received the following error upon migrating an openSUSE Leap 15.6 VM

[20:06:02] Warm migration: planning
[20:06:02] ✓ Authenticated to 10.0.3.20 as administrator@vsphere.local
[20:06:05] ✓ VDDK preflight OK on Proxmox node
[20:06:07] ✓ CBT enabled on source
[20:06:10] ✓ Target VM 158 created on jh1-pve-node03
[20:06:17] Disk 0: zeroed thick target /dev/vg-jh1-isp-t1-hue-do-is-mpatha/vm-158-disk-0
[20:06:17] Disk 0: target JH1-ISP-T1-HUE-DO-IS-LVM-TK:vm-158-disk-0 → /dev/vg-jh1-isp-t1-hue-do-is-mpatha/vm-158-disk-0 (20.0 GB)
[20:10:45] Disk 1: zeroed thick target /dev/vg-jh1-isp-t1-hue-do-is-mpatha/vm-158-disk-1
[20:10:45] Disk 1: target JH1-ISP-T1-HUE-DO-IS-LVM-TK:vm-158-disk-1 → /dev/vg-jh1-isp-t1-hue-do-is-mpatha/vm-158-disk-1 (500.0 GB)
[20:10:45] Full copy (CBT allocated map)…
[22:00:13] ✓ Full copy done: 519.76 GB at 81 MB/s
[22:41:37] Delta pass 1: 13932.0 MB
[23:01:57] Delta pass 2: 10716.9 MB
[23:26:54] Delta pass 3: 6099.1 MB
[23:46:39] Delta pass 4: 4204.8 MB
[00:27:34] Delta pass 5: 7122.9 MB
[00:27:34] ✗ Warm migration failed: Invalid prisma.migrationJob.update() invocation: { where: { id: "cmrme5js001g301nkmrx9eyct" }, data: { status: "delta_sync", currentStep: "operator_gate", operatorGateDowntimeSec: 2505, ~~~~~~~~~~~~~~~~~~~~~~~ ? id?: String | StringFieldUpdateOperationsInput, ? tenantId?: String | StringFieldUpdateOperationsInput, ? sourceConnectionId?: String | StringFieldUpdateOperationsInput, ? sourceVmId?: String | StringFieldUpdateOperationsInput, ? sourceVmName?: String | NullableStringFieldUpdateOperationsInput | Null, ? sourceHost?: String | NullableStringFieldUpdateOperationsInput | Null, ? targetConnectionId?: String | StringFieldUpdateOperationsInput, ? targetNode?: String | StringFieldUpdateOperationsInput, ? targetStorage?: String | StringFieldUpdateOperationsInput, ? targetVmid?: Int | NullableIntFieldUpdateOperationsInput | Null, ? config?: NullableJsonNullValueInput | Json, ? progress?: Int | IntFieldUpdateOperationsInput, ? totalDisks?: Int | NullableIntFieldUpdateOperationsInput | Null, ? currentDisk?: Int | NullableIntFieldUpdateOperationsInput | Null, ? bytesTransferred?: BigInt | NullableBigIntFieldUpdateOperationsInput | Null, ? totalBytes?: BigInt | NullableBigIntFieldUpdateOperationsInput | Null, ? transferSpeed?: String | NullableStringFieldUpdateOperationsInput | Null, ? error?: String | NullableStringFieldUpdateOperationsInput | Null, ? logs?: NullableJsonNullValueInput | Json, ? startedAt?: DateTime | NullableDateTimeFieldUpdateOperationsInput | Null, ? completedAt?: DateTime | NullableDateTimeFieldUpdateOperationsInput | Null, ? createdAt?: DateTime | DateTimeFieldUpdateOperationsInput, ? updatedAt?: DateTime | DateTimeFieldUpdateOperationsInput, ? createdBy?: String | NullableStringFieldUpdateOperationsInput | Null } } Unknown argument operatorGateDowntimeSec. Available options are marked with ?.

Another FYI - the copy button of the migration logs doesn't work :-)

Kind Regards,
Neil

[adminsyspro]

Hi Neil,

Thank you for the detailed report and logs. Both issues are addressed in the upcoming release (PR #563):

1. Warm migration crash (operatorGateDowntimeSec / Prisma error)

The crash happened because the pipeline wrote a field that did not exist in the database schema. This only triggered when delta passes could not converge below the downtime budget (your 500 GB write-active VM produced large deltas across all 5 passes, projecting ~2505 s of downtime vs. the 300 s budget).

The fix replaces the crash with an interactive cutover flow:

• After 5 delta passes, if projected downtime still exceeds the budget, the migration pauses into an awaiting_cutover state instead of throwing.
• A "Cutover now" button appears in the UI with the estimated downtime, letting you decide when to proceed.
• The SOAP/VDDK session stays alive during the wait (2 h safety timeout), so no work is lost.
• If delta convergence happens within budget on any earlier pass, the migration cuts over automatically as before.

2. Copy button not working

The clipboard API (navigator.clipboard.writeText) silently fails over plain HTTP or a LAN IP (common for self-hosted setups). All copy buttons across the app now use a shared helper with an execCommand fallback that works in non-secure contexts.

We will reply here again once the release is published.

Kind regards