1.0 migration 🧵

[pine forge]

@ancient flower I need your help to carefully review the dagger migrate feature in the workspace branch (soon to be tagged with 1.0.0-beta1) so we can polish it together. It has to be perfect so that users with existing Dagger installations can smoothly upgrade and not hate the experience (and ideally: actively love it)

Review, understand deeply - what, why, how - and report back

[ancient flower]

I’m going to review dagger migrate end to end: intent, user flow, implementation, edge cases, tests, and upgrade risk. I’ll report back with concrete findings and polish recommendations.

💻

Fix dagger migrate lock side effects
Codex is implementing the blocker fix in dagger/dagger: lockfile changes should be part of the migration changeset, not staged during planning. Next step: patch code, add regression tests, run focused tests, push codex/* branch and open PR.

[pine forge]

Any progress?

[ancient flower]

Yes. I found one blocker-class issue and a few polish risks.

Main finding: Workspace.migrate() currently stages workspace lock entries during planning, before the user applies the changeset. That means dagger migrate preview/discard can still mutate .dagger/lock for projects with remote refs or pins. The mutation path is core/schema/workspace_migrate.go: migration builds the changeset, then calls stageWorkspaceMigrationLock, which calls query.SetCurrentWorkspaceLookup; the server later flushes that dirty lock to host outside the migration changeset. This violates the design contract that migration application happens only through the returned Changeset.

I’d fix that before beta: lockfile updates should be planned as per-workspace files inside the migration changeset, with tests proving preview/discard leaves lockfiles untouched and nested migrations write locks to the right .dagger/lock.

Other notes so far:

• migrate is DoNotCache, but the CLI asks for changes.ID() and then steps/warnings, so planning can replay. That explains duplicate spans and can make warnings come from a different planning pass than the changeset.
• If .dagger/config.toml already exists, migration returns “No migration needed” without scanning legacy child dagger.json files. Maybe intended, but the message is misleading for partial adopters.
• Upgrade docs still say config.* / [modules.*.config], while the implementation and CLI use settings / [modules.*.settings].

I’m writing this up cleanly now, but the lockfile side effect is the big one.

💻

[pine forge]

@ancient flower go ahead and open PRs on all the repos