Skip to content

[RAPTOR-18959] feat(workload): stop reading legacy .wapi state - #781

Closed
wojtekwdr wants to merge 1 commit into
wojtekw/RAPTOR-18959-remove-workload-feature-gatefrom
wojtekw/RAPTOR-18959-retire-legacy-wapi
Closed

[RAPTOR-18959] feat(workload): stop reading legacy .wapi state#781
wojtekwdr wants to merge 1 commit into
wojtekw/RAPTOR-18959-remove-workload-feature-gatefrom
wojtekw/RAPTOR-18959-retire-legacy-wapi

Conversation

@wojtekwdr

Copy link
Copy Markdown
Contributor

RATIONALE

WAPI GA is the cutoff for the pre-GA on-disk state layout. dr artifact code kept 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

EnsureMigrated and the Dir() fallback are gone, along with StaleRollbackDirs and the migrationNote plumbing 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 read

A 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_WORKLOAD was 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. So wapi.LegacyState recognises the old layout and every affected command explains itself:

Error: not linked: .wapi/ holds state written by an older CLI, which is no longer read.
Run 'dr artifact code init art-abc-123' to link this project again, then delete .wapi/

up refuses before it touches the server. dr artifact code init still 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 .gitignore of *, 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.go so a future release deletes one file rather than hunting fragments.

Residual cost, not fixed

A .wapi/.rollback tree 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.

.wapi stays in ignore.systemExcludes and 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-test or /trigger-test-smoke - Run smoke tests
  • /trigger-install-test or /trigger-test-install - Run installation tests

Labels: Apply labels to trigger workflows:

  • run-smoke-tests or go - Run smoke tests on demand (only works for non-forked PRs)

Important

For Forked PRs: The run-smoke-tests label won't work. A required Smoke Tests check will block merge until a maintainer acts:

  • A maintainer uses /approve-smoke-tests to run smoke tests (results will set the check)
  • A maintainer uses /skip-smoke-tests to bypass the check without running tests

Please comment requesting a maintainer review if you need smoke tests to run.

@datarobot-pr-review-router

Copy link
Copy Markdown

🎫 Jira: RAPTOR-18959 — Remove the DATAROBOT_CLI_FEATURE_WORKLOAD feature gate for WAPI GA

Comment on lines +147 to +149
if _, legacy := wapi.LegacyState(dir); legacy {
return Result{}, wapi.NotLinkedError(dir)
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

Suggested change
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.

@wojtekwdr wojtekwdr closed this Aug 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants