[RAPTOR-18959] feat(workload): stop reading legacy .wapi state - #781
Conversation
|
🎫 Jira: |
| if _, legacy := wapi.LegacyState(dir); legacy { | ||
| return Result{}, wapi.NotLinkedError(dir) | ||
| } |
There was a problem hiding this comment.
the up guard reads too broad. LegacyState(dir) fires whenever .wapi/ is present, but the refusal only makes sense when the project is actually unlinked.
once someone runs dr artifact code init to recover (which you deliberately let succeed alongside .wapi/), they've got both .datarobot/workload/ and a leftover .wapi/. up then refuses a properly-linked project, and NotLinkedError even points them back at the old id from .wapi/config.json, not the one they just linked. so the documented recovery (init then deploy) is broken unless they happen to rm -r .wapi/ in between, which init only says they "can" do.
gating on Exists keeps the second-artifact protection and fixes the false positive:
| if _, legacy := wapi.LegacyState(dir); legacy { | |
| return Result{}, wapi.NotLinkedError(dir) | |
| } | |
| if !wapi.Exists(dir) { | |
| if _, legacy := wapi.LegacyState(dir); legacy { | |
| return Result{}, wapi.NotLinkedError(dir) | |
| } | |
| } |
codesync/phase0 already key off Exists, so this lines up with them. the rest of the swap reads clean.
RATIONALE
WAPI GA is the cutoff for the pre-GA on-disk state layout.
dr artifact codekept its state in a root.wapi/until it moved under.datarobot/workload/, and the CLI has carried an auto-migration plus a read fallback ever since. This retires both.Stacked on #780, which removes the feature gate. Review that one first. Split out because this half carries a breaking change and should not hold up the GA ungate.
CHANGES
EnsureMigratedand theDir()fallback are gone, along withStaleRollbackDirsand themigrationNoteplumbing through the sync engine and four commands.Dir()is now a pure path join, which incidentally means error formatting no longer stats the disk just to build a message string.Breaking change: legacy
.wapi/state is no longer readA project still holding a root
.wapi/reads as unlinked.That directory shipped from v0.2.63 through v0.2.81. The auto-migration that would have relocated it existed only in v0.2.82 and v0.2.83, so anyone who skipped those two releases gets no migration at all. The affected population is gate-opting early adopters by definition, since exporting
DATAROBOT_CLI_FEATURE_WORKLOADwas the only way to create the directory in the first place.One path degraded badly without a guard. Every command reports a visible "not linked" error except
dr workload up, which read the project as a first deploy, minted a second artifact server-side and orphaned the one the project had been pushing to, along with its builds and locked versions, silently. Sowapi.LegacyStaterecognises the old layout and every affected command explains itself:uprefuses before it touches the server.dr artifact code initstill succeeds, because re-linking is the recovery, but it now prints a note that the old directory is orphaned. Naming the artifact id is the point:.wapi/carries a.gitignoreof*, so nothing else would ever surface it, and that id is the only way back.A project that was genuinely never linked still gets the plain hint, with no mention of a directory it does not have.
The whole legacy story now lives in
internal/workload/wapi/legacy.goso a future release deletes one file rather than hunting fragments.Residual cost, not fixed
A
.wapi/.rollbacktree left by a sync that crashed on v0.2.81 or earlier is no longer swept, and those backups are the only copy of the files that sync overwrote. Recovering it would mean keeping half the legacy machinery alive. Flagging it here rather than burying it; the guard at least makes the surrounding situation visible. This is the part worth arguing about..wapistays inignore.systemExcludesand that is deliberate: a leftover directory must never be uploaded as project source, precisely because it can hold that rollback tree.PR Automation
Comment-Commands: Trigger CI by commenting on the PR:
/trigger-smoke-testor/trigger-test-smoke- Run smoke tests/trigger-install-testor/trigger-test-install- Run installation testsLabels: Apply labels to trigger workflows:
run-smoke-testsorgo- Run smoke tests on demand (only works for non-forked PRs)Important
For Forked PRs: The
run-smoke-testslabel won't work. A required Smoke Tests check will block merge until a maintainer acts:/approve-smoke-teststo run smoke tests (results will set the check)/skip-smoke-teststo bypass the check without running testsPlease comment requesting a maintainer review if you need smoke tests to run.