[RAPTOR-20092] fix(workload): a rebuilt wizard draft no longer shows the suggested name as typed - #897
Conversation
|
🎫 Jira: |
Code OwnershipWorkload Cli
Review requested from the teams above. Labels will be removed automatically upon approval. |
|
/approve-smoke-tests |
|
🔐 Fork PR smoke tests triggered by @wojtekwdr What happens next:
|
|
🔐 Fork smoke tests started by maintainer ⏳ Security scans passed. Running smoke tests... Commit: |
|
✅ All smoke tests passed! (Fork PR) ✅ Security Scan: success |
8775ab4 to
204e3ea
Compare
adamalpi
left a comment
adamalpi
left a comment
There was a problem hiding this comment.
Traced every path that touches nameGiven; the invariant holds and the two new tests cover both reset sites with the right control case. Two non-blocking notes inline, both anchored here because neither has an exact line in the diff.
|
/approve-smoke-tests |
|
🔐 Fork PR smoke tests triggered by @wojtekwdr What happens next:
|
|
🔐 Fork smoke tests started by maintainer ⏳ Security scans passed. Running smoke tests... Commit: |
|
✅ All smoke tests passed! (Fork PR) ✅ Security Scan: success |
204e3ea to
cf249e7
Compare
…the suggested name as typed The flag that marks the name as typed survived the two places that rebuild the draft from the flags: choosing another directory on the way back, and setting up a new workload after looking at an existing one. The fresh draft's directory suggestion then came back as a typed value. The draft and the flag now move together, so a restart starts the name over too.
cf249e7 to
6db6248
Compare
|
/approve-smoke-tests |
|
🔐 Fork PR smoke tests triggered by @wojtekwdr What happens next:
|
|
🔐 Fork smoke tests started by maintainer ⏳ Security scans passed. Running smoke tests... Commit: |
|
✅ All smoke tests passed! (Fork PR) ✅ Security Scan: success |
datarobot-pr-review-router
Bot
removed
00 - Ready for Review
Needs Review: Workload CLI
labels
2 participants
RATIONALE
Follow-up from the review of #856. The wizard tracks whether the name on screen was typed or only suggested, and that flag survived the two places that rebuild the draft: picking a different directory on the way back, and choosing "set up a new workload" after having looked at an existing one. Either way the fresh draft's suggestion came back as a typed value, one Enter away from naming a deployed workload after its directory, which is what the name screen exists to prevent.
CHANGES
The draft and the flag now move together through one small flow method, so the two cannot drift again. A changed directory is a restart, so everything answered for the old tree's draft goes with it, the typed name included. Re-choosing the same directory keeps it.
TESTING
Run
dr workload config --dry-runfrom a directory whose only project sits in a subdirectory, choose "Use this directory anyway", type a name, then Escape back to the directory question and pick the subdirectory. The name field must come back empty with its placeholder rather than showing the subdirectory's name as a value.Note
Low Risk
Interactive wizard state only; no auth, persistence, or deploy-path changes beyond preventing accidental one-Enter name confirmation.
Overview
Fixes a workload config wizard bug where rebuilding the draft (different directory or “create new workload” after binding) left
nameGiventrue, so the new tree’s suggested name appeared as a typed value and one Enter could deploy with a bad name (e.g.src).Draft install and
nameGivenreset now go throughstartFrom: only a--nameflag still counts as user-given; interactive names typed for the old draft are cleared with the restart.acceptDirectoryand create-new-after-bind callstartFrominstead of assigning the draft alone. Comments spell out that changing directory discards post-directory answers including the typed name; re-selecting the same directory keeps them.Regression tests cover directory switch vs stay-put and create-new after bind.
Reviewed by Cursor Bugbot for commit 8775ab4. Configure here.