Bug: `explode: false` is not handled properly in query parameters

GPT builders
, ,
1

Hello,

I think there is a bug in the interpretation of explode: false for query parameters.

From the OpenAPI reference:

explode (true/false) specifies whether arrays and objects should generate separate parameters for each array item or object property.

Given the following OpenAPI definition:

{
  "openapi": "3.0.3",
  "paths": {
    "/mesh/": {
      "get": {
        "tags": [
          "Mesh"
        ],
        "summary": "Get all meshes",
        "description": "Get all meshes",
        "operationId": "list_mesh",
        "parameters": [
          {
            "name": "fields[mesh]",
            "in": "query",
            "description": "Specifies the specific fields should be returned. The value **MUST** be a comma-separated\n(U+002C COMMA, “,”) list that refers to the name(s) of the fields to be returned. An empty value\nindicates that no fields should be returned.",
            "required": false,
            "schema": {
              "type": "array",
              "items": {
                "type": "string",
                "enum": [
                  "primitives",
                  "weights",
                  "name"
                ]
              },
              "nullable": true
            },
            "explode": false
          },

my GPT will attempt to run the action with the following query string:

/mesh/?fields%5Bmesh%5D=name&fields%5Bmesh%5D=primitives

Which is obviously wrong, since it should be:

/mesh/?fields%5Bmesh%5D=name,primitives

But it gets worse: most of the time, the GPT won’t even go as far as trying to query my server: it will fail early during what I assume is the validation of the action’s query against the provided OpenAPI definition for that action.

When I try to debug this kind of parameter in the GPT editor, it is apparently properly understood. But when I try to actually run the corresponding action it does not work:

image
image1349×1059 66.3 KB

There is an inconsistency between how the OpenAPI definition is validated and how the query parameters are effectively serialized:

{
  "domain": "mesh.api.gltf.live",
  "method": "get",
  "path": "/mesh/",
  "operation": "list_mesh",
  "operation_hash": "01efab8c08c1af6b81c63ba697c420153dc6ca20",
  "is_consequential": false,
  "params": {
    "fields[mesh]": "name,primitives",
    "include": "primitives"
  }
}

{
  "response_data": "ApiTypeError: Expected fields[mesh] to be a list"
}

IMHO "fields[mesh]": "name,primitives" is valid, so the ApiTypeError is a false positive and it’s a bug.

2

When asked about the ApiTypeError, here is what my GPT answers:

The ApiTypeError in the logs typically indicates that the input parameters provided to the API call do not match the expected format or type as defined in the API specification or schema. This error can occur if the data types, required fields, or structural format of the parameters do not adhere to what is explicitly defined in the OpenAPI definition you provided.

As for how API calls are validated against the OpenAPI definition:

  1. Schema Validation: Before making an API request, the inputs are validated against the schema defined in the OpenAPI documentation. This schema specifies the expected types (e.g., string, integer, array), the required fields, and additional constraints such as enums or patterns.
  2. Parameter Validation: The tool checks if all required parameters are present and whether optional parameters, if included, are in the correct format. This helps prevent requests that are bound to fail from being sent.
  3. Error Handling: If the inputs do not match the schema, the API client (the tool making the API call) generates an error such as ApiTypeError. This error stops the request from being sent and provides feedback on what went wrong, helping to identify issues like type mismatches or missing required fields.

I think that it clearly points to a bug in the OpenAPI definition validation code on OpenAI’s side.