Skip to content

fix: double-encode forward slashes in API path segments for prompt names with slashes#1

Open
neuralmint wants to merge 1 commit into
masterfrom
fix-slash-encoding-prompt-names
Open

fix: double-encode forward slashes in API path segments for prompt names with slashes#1
neuralmint wants to merge 1 commit into
masterfrom
fix-slash-encoding-prompt-names

Conversation

@neuralmint
Copy link
Copy Markdown
Owner

Fixes MagnivOrg#254

Problem

When a prompt name contains a forward slash (e.g. feature1/resolve_problem_2), the Python client fails to fetch it because the unencoded slash creates a new path segment in the URL.

The PromptLayer edge proxy decodes %2F once before routing, so single-encoded slashes still break. Double-encoding as %252F ensures slashes survive proxy decode.

Changes

  1. New helper _quote_api_path_segment() that double-encodes forward slashes
  2. Applied to get_prompt_template, aget_prompt_template, _resolve_workflow_id
  3. Unit tests + updated existing tests

When a prompt name (or workflow name) contains a forward slash, the
edge proxy decodes %2F before routing the path parameter, causing the
request to hit the wrong endpoint. Double-encoding slashes as %252F
ensures they survive one decode pass and arrive at the application as
%2F.

Changes:
- Add _quote_api_path_segment() helper that encodes all special chars
  and double-encodes forward slashes (%2F → %252F)
- Apply helper in get_prompt_template, aget_prompt_template, and
  _resolve_workflow_id
- Add unit tests for the helper and integration-style tests for the
  three call sites

Closes MagnivOrg#254
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.

Client fails to fetch prompts with names containing slash

1 participant