When creating a plugin for a OpenAPI description with no operationId, the plugin is created with no functions or runtime info

[maisarissi]

What are you generating using Kiota, clients or plugins?

Kiota plugin

In what context or format are you using Kiota?

Source Build

Client library/SDK language

None

Describe the bug

When trying to create a plugin form an OpenAPI description with no operationId, Kiota is able to generate the right sliced OpenAPI description:

openapi: 3.0.1
info:
  title: JSONPlaceholder
  version: '1.0'
servers:
  - url: https://jsonplaceholder.typicode.com/
paths:
  /posts:
    get:
      description: Get posts
      parameters:
        - name: userId
          in: query
          description: Filter results by user ID
          style: form
          schema:
            maxItems: 1
            type: integer
        - name: title
          in: query
          description: Filter results by title
          style: form
          schema:
            maxItems: 1
            type: string
      responses:
        '200':
          description: OK
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/post'
components:
  schemas:
    post:
      type: object
      properties:
        userId:
          type: integer
        id:
          type: integer
        title:
          type: string
        body:
          type: string
  parameters:
    post-id:
      name: post-id
      in: path
      description: 'key: id of post'
      required: true
      style: simple
      schema:
        type: integer

However, the plugin manifest is created with no functions or runtime:

{
  "schema_version": "v2",
  "name_for_human": "JSONPlaceholder",
  "description_for_human": "Description for JSONPlaceholder",
  "description_for_model": "Description for JSONPlaceholder",
  "namespace": "getplugin",
  "capabilities": {
    "localization": {}
  }
}

Expected behavior

The plugin manifest should have a functions and runtime objects even when the OpenAPI description has no operationId

How to reproduce

Use the OpenAPI description above to create a plugin

Open API description file

No response

Kiota Version

workspace feature

Latest Kiota version known to work for scenario above?(Not required)

No response

Known Workarounds

No response

Configuration

No response

Debug output

Click to expand log

```

</details>


### Other information

_No response_

[baywet]

@maisarissi what would you have as a placeholder?
I'm assuming the sliced description also needs the operationId to be set, correct?

[sebastienlevert]

They are not required. At runtime, random GUIDs will be generated to ensure their unicity.

[baywet]

so we don't need to change anything here?

[sebastienlevert]

We need to generate the functions in the plugin for sure. If they are not generated, they are ignored and won't get called.

[baywet]

ok so back to my previous question, I'm guessing we're using a guid as a placeholder. And I'm guessing the sliced description needs the same guid as operation id?

[sebastienlevert]

Do we have better ways to generate operation Ids based on the path? I feel it would be a lot more dev friendly.

[maisarissi]

Maybe we could generate an operationId combining the endpoint with the HTTP method?
Something like: posts#GET could be posts-list, then posts/{posts-id}#GET could be posts-get, posts#PATCH posts-patch, posts/{posts-id}/comments#GET posts-comments-list, posts/{posts-id}/comments/{comment-id}#GET posts-comments-get and so on and so forth.

[andrueastman]

According to the validator, we would need the operationId to have the format ^[a-zA-Z0-9_]*$ (essentially number,digits and underscores). So, using something like posts-list would lead to validation error by the plugins lib and we would need to use underscores instead rather than the dash.

Another idea is that we can use the same logic Kiota uses for namespacing for a path and append the operation name at the end and separating them with underscores.
posts#GET => posts_get
posts/{posts-id}#GET => posts_item_get
posts/{posts-id}/comments#GET => posts_item_comments_get
posts/{posts-id}/comments/{comment-id}#GET => posts_item_comments_item_get

Back to the question by @baywet, we probably need to answer,

• Should the openApi file that is also generated/sliced from the original description at output also be updated with the added operationIds to match?
• Should we attempt to sanitize operationId for the sake of the validator if the original operationId does not match the plugin validation rules? (and update the openApi description as well?).

[sebastienlevert]

That's a great proposal @andrueastman. I think this would be optimal! For the questions:

• I'd say yes. The orchestrator will report on the operationIds used (not the function names from the plugin) and it'll be super useful for debugging later as devs will know which operation was called.
• This is a good question... And I think this is a fair way to ensure success. I'd vote for sanitizing both the plugin function names and the operationIds in a consistent manner. Basically "always" sanitize them to ensure full supportability.

[maisarissi]

Agree with @sebastienlevert.

• Yes, we should add the operationIds to the sliced OpenAPI description.
• If the existing operationId in the original OpenAPI document does not match with the validation rules, we should ensure success and sanitize them to successfully generate the sliced OpenAPI and the plugin.