Skip to content

Box provisioning: consider folding detection connection into runner's lock-holding connection #4146

@iancooper

Description

@iancooper

Context

SqlBoxProvisioner.ProvisionAsync opens a detection-only connection (pre-lock detection + payload-mode validation), closes it, then SqlBoxMigrationRunner.MigrateAsync opens its own lock-holding connection. For deployments with many box tables and strict per-pod connection caps, this doubles startup connection establishment cost.

A previous review iteration (item #11 on PR #4039) already folded the detection + payload-validation steps into a single connection. Extending the fold to the runner's lock-holding connection is the natural next step.

Suggested change

Restructure IAmABoxMigrationRunner.MigrateAsync to accept a pre-opened connection rather than owning the connection lifecycle. The provisioner would then own one connection for detection → payload-mode validation → migration runner → release.

Trade-off: today, the runner's connection lifecycle is isolated from the provisioner's, which keeps its retry/cancellation policy local. Folding couples the two — the trade is real but bounded (the runner already runs sequentially after the provisioner's detection phase). Worth a small spike before committing to a refactor.

References

Metadata

Metadata

Assignees

Type

No fields configured for Task.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions