[Sankalp-Mittal]

Why

DMS marks a version IN_PROGRESS at CreateVersion. If the CLI dies before CompleteVersion, nothing refreshes the version and the UI shows it as deploying forever.

Design (meeting notes: Nov 2, Nov 3):

• The service keeps one last-update time per version, refreshed by every UpdateOperation and by Heartbeat, and exposes it as Version.update_time. CreateVersion still rejects while the previous version's 2-minute lease (last write or heartbeat + 2 min) is live and closes an expired one as LEASE_EXPIRED, so writes and heartbeats both extend that lease. No auto-close; deploy.lock stays for now and will be removed in a later update.
• The UI shows a version as interrupted once update_time is over 2 minutes old. The state is recoverable.
• The CLI's job is to keep that time fresh while a version is open. Without heartbeats, a resource that takes over 2 minutes with no state write lets a second deploy take the version and the first one's writes then fail.

What

• libs/dms/heartbeat.go: a goroutine per open version. It calls POST .../versions/{v}/heartbeat only after 30s with no successful UpdateOperation, so a fast deploy sends none. A failed heartbeat is reported once as a warning (the deployment may show as interrupted) and tried again at the next interval; the SDK already retries transient errors inside each call. It never fails or stops the deploy.
• libs/dms/operation_buffer.go: a successful write resets the heartbeat timer.
• bundle/direct/dstate/state.go: the heartbeat starts with the operation buffer (right after CreateVersion, so deploy and destroy are both covered) and stops in CompleteVersion before the RPC.
• No request shapes change; HeartbeatResponse.expire_time is ignored.

Dependencies

• Server PR databricks-eng/universe#2983937: writes refresh the version timestamp and Version.update_time is exposed. Until it lands, a deploy that writes more often than every 30s sends no heartbeat. Nothing reads the field yet, so this is not a regression.
• UX PR (separate): show "interrupted" after 2 minutes. Must land after both.

Tests

• libs/dms/heartbeat_test.go: testing/synctest with the real 30s constants: beats while idle, a write skips the beat, a failure warns and tries again next interval, Stop().
• acceptance/bundle/dms is unchanged: fixtures finish in under 30s, so no heartbeat is recorded. The fake server already serves the endpoint.
• No .nextchanges fragment: DMS is experimental and the change is invisible until the UX PR lands.

This pull request and its description were written by Isaac.

[eng-dev-ecosystem-bot]

✅ Integration test report

Commit: 27a6b92

Run: 42206315238

	Env	✅​pass	🙈​skip	Time
✅​	aws linux-2core-8gb	271	15	4:43
✅​	aws-windows-latest-4core-16gb	273	13	3:13
✅​	azure linux-2core-8gb	270	15	3:41
✅​	azure-windows-latest-4core-16gb	272	13	3:13
✅​	gcp linux-2core-8gb	271	15	5:15
✅​	gcp-windows-latest-4core-16gb	273	13	3:04

Top 3 slowest tests (at least 2 minutes):

duration	env	testname
3:08	azure-windows-latest-4core-16gb	TestAccept
3:07	aws-windows-latest-4core-16gb	TestAccept
2:58	gcp-windows-latest-4core-16gb	TestAccept