Fix step.request_parse wildcard path parameter extraction ({param...})

[Copilot]

step.request_parse failed to extract wildcard path parameters ({param...}) introduced in Go 1.22+: the ... suffix was retained in the param name (causing lookup misses), and only the first path segment was captured instead of the full remainder.

Changes

• module/pipeline_step_request_parse.go: In the pattern-matching loop, detect ... suffix on param names, strip it, and join all remaining path segments (actualParts[i:]) for wildcard params instead of capturing a single segment.

// Before
paramName := pp[1 : len(pp)-1]  // "resource..." — lookup fails, single segment captured

// After
paramName := pp[1 : len(pp)-1]
isWildcard := strings.HasSuffix(paramName, "...")
if isWildcard {
    paramName = strings.TrimSuffix(paramName, "...")
}
if i < len(actualParts) {
    if isWildcard {
        paramMap[paramName] = strings.Join(actualParts[i:], "/")
    } else {
        paramMap[paramName] = actualParts[i]
    }
}

• module/pipeline_step_request_parse_test.go: Added tests for multi-segment (/api/forms/test-form → resource = "forms/test-form") and single-segment (/api/forms → resource = "forms") wildcard capture.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Bug: step.request_parse does not handle {param...} wildcard path parameters</issue_title>
<issue_description>## Bug Description

step.request_parse does not correctly handle Go 1.22+ wildcard path parameters ({param...}). When a route pattern uses the ... suffix for multi-segment matching, the step fails to extract the parameter value for two reasons:

1. Parameter name mismatch: The ... suffix is included in the extracted parameter name. For pattern {resource...}, the internal paramMap key becomes "resource...", but the path_params config specifies "resource" (without ...). The lookup fails because the keys don't match.

2. Single-segment capture only: The path parsing logic (actualParts[i]) only captures a single path segment at the matching position. For wildcard parameters that should capture the remainder of the path (e.g., /api/forms/test-form → resource = "forms/test-form"), only the first segment is captured ("forms").

Steps to Reproduce

1. Define a pipeline with a wildcard route pattern:

pipelines:
  proxy-api:
    trigger:
      type: http
      config:
        path: /api/{resource...}
        method: GET
    steps:
      - name: parse
        type: step.request_parse
        config:
          path_params: [resource]

2. Send a request to /api/forms/test-form

3. Check path_params.resource in the step output → empty string (expected: "forms/test-form")

Root Cause

In pipeline_step_request_parse.go, the parameter extraction logic (lines ~92-100):

paramName := pp[1 : len(pp)-1]  // {resource...} → "resource..." (includes ...)
if i < len(actualParts) {
    paramMap[paramName] = actualParts[i]  // only captures one segment
}

Issue 1: Name includes ...

pp[1:len(pp)-1] strips the { and } but retains ..., producing "resource..." instead of "resource".

Issue 2: Single-segment capture

actualParts[i] only captures the segment at position i. For wildcard params, it should join all segments from position i onward.

Expected Behavior

For route pattern /api/{resource...} and request path /api/forms/test-form:

• path_params.resource should equal "forms/test-form" (all remaining segments joined)

For route pattern /api/{resource...} and request path /api/forms:

• path_params.resource should equal "forms" (single remaining segment)

Proposed Fix

paramName := pp[1 : len(pp)-1]
isWildcard := strings.HasSuffix(paramName, "...")
if isWildcard {
    paramName = strings.TrimSuffix(paramName, "...")
}

if i < len(actualParts) {
    if isWildcard {
        // Capture all remaining path segments for wildcard params
        paramMap[paramName] = strings.Join(actualParts[i:], "/")
    } else {
        paramMap[paramName] = actualParts[i]
    }
}

Workaround

Use req.PathValue("resource") (Go 1.22+) which correctly handles wildcards, or extract the path directly from the request URL by stripping the known prefix.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Bug: step.request_parse does not handle {param...} wildcard path parameters #229

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Copilot]

Pull request overview

Fixes step.request_parse so it correctly extracts Go 1.22+ wildcard path parameters ({param...}) by stripping the ... suffix from the parameter name and capturing the full remaining path instead of a single segment.

Changes:

• Update wildcard path param extraction to (1) normalize param names by trimming ... and (2) join remaining path segments for wildcard matches.
• Add unit tests covering wildcard capture for both multi-segment and single-segment paths.
• Update indirect dependencies in example/ module files (go.mod/go.sum).

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.

File	Description
module/pipeline_step_request_parse.go	Fix wildcard {param...} extraction by trimming suffix and joining remaining segments.
module/pipeline_step_request_parse_test.go	Add coverage for wildcard params capturing multiple vs. single segments.
example/go.mod	Indirect dependency version updates/removals in the example module.
example/go.sum	Corresponding go.sum churn for the example module dependency changes.