fix(composer): expand template expressions in elicitation messages

[saschabuehrle]

Bug

#4312 — Template expressions like {{.params.owner}} in elicitation step message fields are passed through as raw placeholders instead of being expanded.

Fix

Adds template expansion for step.Elicitation.Message in executeElicitationStep() before passing it to RequestElicitation(). This mirrors how executeToolStep() already expands step.Arguments through the template expander (line ~404).

The expansion wraps the message string in a temporary map to reuse the existing public TemplateExpander.Expand() interface, keeping the change minimal and consistent with the established expansion pattern.

Testing

• Added TestWorkflowEngine_ElicitationMessageTemplateExpansion integration test that verifies {{.params.repo}} and {{.params.env}} placeholders in an elicitation message are expanded to their resolved values before reaching the SDK elicitation requester.

Happy to address any feedback.

Greetings, saschabuehrle

[jerm-dro]

Thanks for picking this up! Two requests before merging: avoid mutating the step definition (use an immutable assignment pattern), and restructure the test as table-driven with a few more cases. Details in the inline comments.

[jerm-dro]

This mutates step.Elicitation.Message in place. Since step is a pointer to the workflow definition, the original template could be lost after expansion — e.g., if workflows are re-executed or steps retried, the template wouldn't be available for re-expansion.

Compare with executeToolStep (line 404) which stores the expanded result in a local expandedArgs variable and never modifies step.Arguments.

Suggest constructing the config immutably via an immediately-invoked function, and passing the result to RequestElicitation:

// Expand template expressions in elicitation message (e.g. {{.params.owner}})
elicitCfg, err := func() (*ElicitationConfig, error) {
    if step.Elicitation.Message == "" {
        return step.Elicitation, nil
    }
    wrapper := map[string]any{"message": step.Elicitation.Message}
    expanded, expandErr := e.templateExpander.Expand(ctx, wrapper, workflowCtx)
    if expandErr != nil {
        return nil, fmt.Errorf("%w: failed to expand elicitation message for step %s: %v",
            ErrTemplateExpansion, step.ID, expandErr)
    }
    if msg, ok := expanded["message"].(string); ok {
        cfgCopy := *step.Elicitation
        cfgCopy.Message = msg
        return &cfgCopy, nil
    }
    return step.Elicitation, nil
}()
if err != nil {
    workflowCtx.RecordStepFailure(step.ID, err)
    return err
}

response, err := e.elicitationHandler.RequestElicitation(ctx, workflowCtx.WorkflowID, step.ID, elicitCfg)

[jerm-dro]

Could you restructure this as a table-driven test? The happy path is well covered, but there are a few more cases worth exercising. Something like:

func TestWorkflowEngine_ElicitationMessageTemplateExpansion(t *testing.T) {
    t.Parallel()

    tests := []struct {
        name            string
        message         string
        params          map[string]any
        expectedMessage string
        expectError     bool
    }{
        {
            name:            "template expressions expanded",
            message:         "Deploy {{.params.repo}} to {{.params.env}}?",
            params:          map[string]any{"repo": "acme/widget", "env": "production"},
            expectedMessage: "Deploy acme/widget to production?",
        },
        {
            name:            "empty message skips expansion",
            message:         "",
            params:          map[string]any{"repo": "acme/widget"},
            expectedMessage: "",
        },
        {
            name:            "no template expressions passes through unchanged",
            message:         "Are you sure?",
            params:          map[string]any{},
            expectedMessage: "Are you sure?",
        },
        {
            name:        "malformed template returns error",
            message:     "Deploy {{.params.repo to env",
            params:      map[string]any{"repo": "acme/widget"},
            expectError: true,
        },
    }
    // ...
}

This matches the table-driven style used elsewhere in this file (e.g., TestDefaultElicitationHandler_SDKErrorHandling).

[saschabuehrle]

Thanks for the review — I’ve gone through the requested changes and queued follow-up updates. I’ll push the revision in a dedicated follow-up pass.

[codecov]

Codecov Report

❌ Patch coverage is 50.00000% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 68.47%. Comparing base (0108b11) to head (0b280a1).
⚠️ Report is 18 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/vmcp/composer/workflow_engine.go	50.00%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4313      +/-   ##
==========================================
- Coverage   68.77%   68.47%   -0.30%     
==========================================
  Files         473      478       +5     
  Lines       47919    48499     +580     
==========================================
+ Hits        32955    33211     +256     
- Misses      12299    12409     +110     
- Partials     2665     2879     +214     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[saschabuehrle]

Pushed an update for both points.

The step config stays immutable now (message expansion happens on a copied elicitation config), and the integration coverage is table-driven with both templated and plain message cases.

Greetings, saschabuehrle