Possible bug with 'deepObject' query parameters

I’m trying to support a new query parameter to a GET endpoint for my plugin. This parameter is a non-nested object, therefore I’m using the ‘deepObject’ style from the openapi spec in my openapi.yaml file.

E.g. Here’s an example query param object I’m looking to support:

{
  "created_at": {
    "lt": "2023-07-21T00:00:00Z"
  }
}

Unfortunately, any request I try to make using this fails with the message ‘There was an error generating a response’.

image

Looking at the chrome dev tools, and my server logs, no request is made to my server, however there is this error in the console.

Screenshot 2023-07-21 at 14.32.29

My openapi.yaml is valid, and I’ve sanity checked this all using GPT4.


My main questions:

  1. I’m aware that some parts of the openapi spec (e.g. allOf) are not currently supported for plugins, does anyone know if the deepObject style is supported?
  2. Has anyone successfully implemented an object query param for a GET request with ChatGPT plugins?

Thanks in advance.

ps. If anyone is aware of any documentation around which parts of the openapi specification are currently supported, that would be amazing.

I don’t know the answer, but a quick Q, (2 actually) 1) can you post the error in text format (people like to copy paste it for searches) and 2) if you take that part out, does it work ok?

Hi @Foxabilo,

The console error is:

_app-1fb29c81a8f25dfc.js:28 FatalServerError: Error in message stream
    at onmessage (_app-1fb29c81a8f25dfc.js:33:231736)
    at _app-1fb29c81a8f25dfc.js:33:215761
    at _app-1fb29c81a8f25dfc.js:33:215591
    at tt (_app-1fb29c81a8f25dfc.js:33:215318)
    at async tb (_app-1fb29c81a8f25dfc.js:33:217336)

The app also sends a few messages to sentry.io (I assume to report the error, although they are getting a 429 response, so it’s likely that the error is not being properly reported).

if you take that part out, does it work ok?

Not 100% sure which part you’re referring to.

More info: My plugin works fine for all other requests, and it also works with this GET endpoint if the nested object param is not used. If I amend my openapi.yaml to switch the deep object to a regular string parameter, it also works.

Hence why I think the deepObject is the issue, and ChatGPT may not be handling this correctly.

Sorry, I should of been more clear. If you remove the deepObject does it function without error. What I’m attempting to ascertain is the state of the codebase without any use of possibly unimplemented options.

Yep:

My plugin works fine for all other requests, and it also works with this GET endpoint if the nested object param is not used.

1 Like

Does anyone have any ideas on this? The relevant part of my openapi.yaml is:

      parameters:
        - name: created_at
          in: query
          description: Filter by creation date. Use an ISO 8601 string for exact match, or an object for range. Object can have 'lt', 'lte', 'gt', 'gte' fields (for less than, <=, >, >=) with ISO 8601 date-time values.
          style: deepObject
          explode: true
          schema:
            type: object
            properties:
              lt:
                type: string
                format: date-time
                description: Less than the specified date-time.
              lte:
                type: string
                format: date-time
                description: Less than or equal to the specified date-time.
              gt:
                type: string
                format: date-time
                description: Greater than the specified date-time.
              gte:
                type: string
                format: date-time
                description: Greater than or equal to the specified date-time.

Would appreciate any help! :slightly_smiling_face:

Ok, so to wrap this up. After much experimentation, I believe that ChatGPT does not currently support the deepObject style, even though it is part of the openapi spec.

I would love to be proved wrong on this, so if anyone has any working examples, please let me know!

I managed to get around this by using parameters with names which match how the deepObject would have been serialised. i.e.

        - name: created_at[lt]
          in: query
          description: Filter items for those whose created_at is < than the provided ISO 8601 datetime.
          example: '2023-07-20T08:28:40Z'
          schema:
            type: string
            format: date-time
        - name: created_at[lte]
          in: query
          description: Filter items for those whose created_at is <= than the provided ISO 8601 datetime. 
          example: '2023-07-20T08:28:40Z'
          schema:
            type: string
            format: date-time

etc.

As said, if people think I’m wrong here, (or if a fix is implemented) I would love to hear, as I’m keen to make use of this feature. :slightly_smiling_face: