Description
When using the Quarkus OpenAPI Generator extension with GitLab API's project_id path parameter (which accepts URL-encoded project paths), the extension either:
- Doesn't encode slashes when passed unencoded values, causing 404 errors
- Double-encodes already-encoded values, also causing 404 errors
This makes it impossible to use GitLab's project path format (e.g., mygroup/myproject/backend) with the generated REST client.
Problem
GitLab's API accepts project_id as either:
- A numeric project ID (e.g.,
12345)
- A URL-encoded project path (e.g.,
mygroup%2Fmyproject%2Fbackend for mygroup/myproject/backend)
Current Behavior
Scenario 1: Passing unencoded project path
Workflow input data:
{
"project_id": "mygroup/myproject/backend"
}
Workflow action:
- name: "getMergeRequestDetails"
functionRef:
refName: getMergeRequest
arguments:
project_id: .project_id
merge_request_iid: 123
Expected URL: /api/v4/projects/mygroup%2Fmyproject%2Fbackend/merge_requests/123
Actual URL: /api/v4/projects/mygroup/myproject/backend/merge_requests/123
Result: 404 Not Found (GitLab interprets the slashes as path segments)
Scenario 2: Passing pre-encoded project path
Workflow input data:
{
"project_id": "mygroup%2Fmyproject%2Fbackend"
}
Workflow action:
- name: "getMergeRequestDetails"
functionRef:
refName: getMergeRequest
arguments:
project_id: .project_id
merge_request_iid: 123
Expected URL: /api/v4/projects/mygroup%2Fmyproject%2Fbackend/merge_requests/123
Actual URL: /api/v4/projects/mygroup%252Fmyproject%252Fbackend/merge_requests/123
Result: 404 Not Found (The %2F is encoded again to %252F, making it unrecognizable)
Expected Behavior
The OpenAPI Generator should:
- Encode special characters in path parameters (e.g.,
/ → %2F)
- Detect already-encoded values and skip encoding them (avoid double encoding)
OR provide a configuration option to control encoding behavior per path parameter.
OpenAPI Specification
Here's the relevant GitLab API spec showing the project_id parameter usage:
openapi: 3.0.0
info:
title: GitLab Repository Automation API
version: 1.0.0
paths:
/api/v4/projects/{project_id}/merge_requests/{merge_request_iid}:
get:
summary: Get merge request details
operationId: getMergeRequest
parameters:
- name: project_id
in: path
required: true
schema:
type: string
- name: merge_request_iid
in: path
required: true
schema:
type: integer
responses:
'200':
description: Success
'404':
description: Not Found
Description
When using the Quarkus OpenAPI Generator extension with GitLab API's
project_idpath parameter (which accepts URL-encoded project paths), the extension either:This makes it impossible to use GitLab's project path format (e.g.,
mygroup/myproject/backend) with the generated REST client.Problem
GitLab's API accepts
project_idas either:12345)mygroup%2Fmyproject%2Fbackendformygroup/myproject/backend)Current Behavior
Scenario 1: Passing unencoded project path
Workflow input data:
{ "project_id": "mygroup/myproject/backend" }Workflow action:
Expected URL:
/api/v4/projects/mygroup%2Fmyproject%2Fbackend/merge_requests/123Actual URL:
/api/v4/projects/mygroup/myproject/backend/merge_requests/123Result: 404 Not Found (GitLab interprets the slashes as path segments)
Scenario 2: Passing pre-encoded project path
Workflow input data:
{ "project_id": "mygroup%2Fmyproject%2Fbackend" }Workflow action:
Expected URL:
/api/v4/projects/mygroup%2Fmyproject%2Fbackend/merge_requests/123Actual URL:
/api/v4/projects/mygroup%252Fmyproject%252Fbackend/merge_requests/123Result: 404 Not Found (The
%2Fis encoded again to%252F, making it unrecognizable)Expected Behavior
The OpenAPI Generator should:
/→%2F)OR provide a configuration option to control encoding behavior per path parameter.
OpenAPI Specification
Here's the relevant GitLab API spec showing the
project_idparameter usage: