fix: resolve enum refs that depend on dynamic variables in interactive prompts by ikshantshukla123 · Pull Request #2969 · go-task/task

ikshantshukla123 · 2026-08-11T08:52:45Z

Summary

task --interactive showed a free-form text prompt (instead of a selection menu) when an enum.ref pointed to a dynamic sh: variable. The previous enum-ref support (#2927) resolved refs against the fast-compiled task vars, where sh: variables are not evaluated and resolve to "". The ref then produced an empty list and the prompter fell back to Text input.

This PR evaluates the relevant dynamic (sh:) variables first, so the enum ref resolves to the real values and a Select menu is shown.

Changes

resolveEnumRefForPrompt now evaluates dynamic (sh:) variables before resolving the enum ref, then resolves the ref a single time. It reuses the compiler's dynamic-var cache and mirrors GetVariables evaluation order, and a failing command is left unevaluated so the remaining variables can still resolve.
Fixed a bug in the initial implementation: FastGetVariables stores un-evaluated dynamic vars as {Value: "", Sh: ...} (a non-nil empty value), so treating any non-nil value as static meant the sh: command never ran.
All checks pass: go build ./..., go vet ./..., golangci-lint run ./..., and the full root-package test suite.

Tests

Added fixture-based integration test TestPromptEnumRefResolution driving the real prompt path (FastCompiledTask → resolveEnumRefForPrompt) against testdata/enum_ref_prompt/, covering a dynamic sh: ref, a static list ref, and an empty dynamic var.
Reworked the resolveEnumRefForPrompt unit tests to assert the actual resolved enum values for realistic scenarios (fast-compiled var shape, empty dynamic output, failing unrelated sh: var).

Note: a golden end-to-end test like testdata/prompt isn't possible for this path because the requires: prompt uses a bubbletea-based input.Prompter, which can't be driven by the plain-stdin test harness (only the prompt: confirm field can).

AI usage disclosure

I used DeepSeek (via the opencode CLI) to understand the fast-compiled var shape and the templater resolution flow, and to help write the regression tests included in this PR. The duplicate-logic review feedback was applied manually; the streamlined flow is written by hand.

The previous fix for go-task#2958 missed the fast-compiled var shape: FastGetVariables stores un-evaluated dynamic variables as {Value: "", Sh: ...}, so the `newVar.Value != nil` check in evaluateDynamicVarsForPrompt treated them as static and never ran HandleDynamicVar. The enum ref resolved to an empty list and the prompt fell back to free-form input. Only treat a variable as static when it has a non-nil value and no shell command. Add a regression test using the fast-compiled var shape so this cannot regress again.

ikshantshukla123 · 2026-08-12T15:43:37Z

@trulede have a look.

trulede · 2026-08-12T19:49:53Z

 	vCopy := v.DeepCopy()
 	cache := &templater.Cache{Vars: vars}
-	_ = resolveEnumRefs(&ast.Requires{Vars: []*ast.VarsWithValidation{vCopy}}, cache)
+	if err := resolveEnumRefs(&ast.Requires{Vars: []*ast.VarsWithValidation{vCopy}}, cache); err == nil && len(vCopy.Enum.Value) > 0 {


There is a lot of duplicated logic. I would try to streamline it. Evaluate vars, then resolve enum refs, done.

And see about writing tests similar to this if possible:
https://github.com/go-task/task/tree/main/testdata/prompt

Because AI generated tests are next-to-useless.

Done. resolveEnumRefForPrompt is now: evaluate dynamic vars first (when any exist), then resolve the enum ref once — no more two-pass retry or duplicated resolveEnumRefs/DeepCopy.

For tests, since the interactive prompt is bubbletea-based (can't be driven by a plain stdin buffer in the harness, same reason the existing testdata/prompt tests use the prompt: field instead of requires:), I added a fixture-based integration test at testdata/enum_ref_prompt that drives the real prompt path (FastCompiledTask → resolveEnumRefForPrompt) and asserts the resolved enum values, plus targeted unit tests for the edge cases (empty dynamic output, failing unrelated sh: var).

And see about writing tests similar to this if possible: https://github.com/go-task/task/tree/main/testdata/prompt

Because AI generated tests are next-to-useless.

Added fixture-based tests at testdata/enum_ref_prompt/ that run the real prompt path against a Taskfile (dynamic sh: var, static list var, and an empty dynamic var), added in TestPromptEnumRefResolution. The existing unit tests in requires_internal_test.go were reworked to assert the actual resolved enum values for realistic scenarios.

Note: a fully end-to-end golden test like testdata/prompt isn't possible here because the requires: prompt uses a bubbletea-based input.Prompter, which can't be driven by the plain-stdin test harness (only the prompt: confirm field can).

@trulede Ready for rereview whenever you get a chance

Simplify resolveEnumRefForPrompt per review feedback: evaluate dynamic (sh:) variables first when present, then resolve the enum ref once, instead of a two-pass resolve-and-retry that duplicated resolveEnumRefs and DeepCopy. Replace the hand-rolled unit fixtures with a fixture-based integration test that drives the real prompt path (FastCompiledTask + resolveEnumRefForPrompt) against testdata/enum_ref_prompt, plus targeted unit tests for edge cases: empty dynamic output and a failing unrelated sh: var.

trulede · 2026-08-14T21:47:15Z

+	if vars == nil {
+		return false
+	}
+	for v := range vars.Values() {


Should this be for _, v ...

and if wrong, perhaps why the unit test does not fail.

and if wrong, perhaps why the unit test does not fail.

Good question vars.Values() returns iter.Seq[Var] (a single-value iterator, not (k, v) pairs), so for v := range vars.Values() yields each Var directly. for _, v := range wouldn't compile here since iter.Seq[Var] ranges over exactly one variable.
On the test question it's guarded by TestPromptEnumRefResolution — if hasDynamicVars returned false for the dynamic sh: fixture, the enum would come back empty and that test would fail. (And hasDynamicVars is really just a cheap guard; evaluateDynamicVarsForPrompt handles the no-op case fine either way.)

vmaerten · 2026-08-15T07:54:01Z

@trulede thanks for being so patient.

@ikshantshukla123 please refer to our policy on AI.

It's clear that an LLM is posting with your account. It looks like you're pasting trulede's answers to an LLM and then pasting the response back into GitHub (with the associated commit, also generated)

Please don't do that.

ikshantshukla123 · 2026-08-15T08:07:56Z

@trulede thanks for being so patient.

@ikshantshukla123 please refer to our policy on AI.

It's clear that an LLM is posting with your account. It looks like you're pasting trulede's answers to an LLM and then pasting the response back into GitHub (with the associated commit, also generated)

Please don't do that.

Sorry sir but it was not blindly copy pasted , my English is weak so with my pointers I used ai to generate convo. Can you suggest another method?

ikshantshukla123 · 2026-08-15T08:13:10Z

@trulede thanks for being so patient.

@ikshantshukla123 please refer to our policy on AI.

It's clear that an LLM is posting with your account. It looks like you're pasting trulede's answers to an LLM and then pasting the response back into GitHub (with the associated commit, also generated)

Please don't do that.

Sorry sir but it was not blindly copy pasted , my English is weak so with my pointers I used ai to generate convo. Can you suggest another method?

@trulede sir can you give some tips?

trulede · 2026-08-15T09:23:24Z

Yes. Don't paste crap from AI, its always junk. Unit tests written by AI are junk too .... and the project has to maintain that ... which is actually quite some effort.

You simply write that: var.Values() is a slice, the loop works. Write it in you native language and use AI to translate. Simple things translate well.

Use AI to help you, but write the code yourself. And the PR too.

ikshantshukla123 added 2 commits August 9, 2026 13:24

fix: resolve enum refs that depend on dynamic variables

e5532c5

trulede reviewed Aug 12, 2026

View reviewed changes

trulede reviewed Aug 14, 2026

View reviewed changes

vmaerten closed this Aug 15, 2026

ikshantshukla123 deleted the fix/interactive-dynamic-enum-ref branch August 16, 2026 15:55

Uh oh!

Uh oh!

Conversation

ikshantshukla123 commented Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Tests

AI usage disclosure

Uh oh!

ikshantshukla123 commented Aug 12, 2026

Uh oh!

trulede Aug 12, 2026

Choose a reason for hiding this comment

Uh oh!

trulede Aug 12, 2026

Choose a reason for hiding this comment

Uh oh!

ikshantshukla123 Aug 13, 2026

Choose a reason for hiding this comment

Uh oh!

ikshantshukla123 Aug 13, 2026

Choose a reason for hiding this comment

Uh oh!

ikshantshukla123 Aug 14, 2026

Choose a reason for hiding this comment

Uh oh!

trulede Aug 14, 2026

Choose a reason for hiding this comment

Uh oh!

trulede Aug 14, 2026

Choose a reason for hiding this comment

Uh oh!

ikshantshukla123 Aug 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vmaerten commented Aug 15, 2026

Uh oh!

ikshantshukla123 commented Aug 15, 2026

Uh oh!

ikshantshukla123 commented Aug 15, 2026

Uh oh!

trulede commented Aug 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ikshantshukla123 commented Aug 11, 2026 •

edited

Loading

ikshantshukla123 Aug 15, 2026 •

edited

Loading