If a schema has partly overlapping paths which use different names for the parameters, then the URL can be invalid (in java generation at least).

This is the smallest example I can come up with:

openapi: 3.0.3
servers:
  - url: 'https://example.com'
info:
  title: example
  version: 0.0.1
paths:
  '/path/{thingId}/abc/{second}':
    get:
      summary: abc
      operationId: abc
      parameters:
        - name: thingId
          in: path
          required: true
          schema:
            type: string
        - name: second
          in: path
          required: true
          schema:
            type: string
      responses:
        '200':
          description: OK
  '/path/{differentThingId}/def/{second}':
    get:
      summary: def
      operationId: def
      parameters:
        - name: differentThingId
          in: path
          required: true
          schema:
            type: string
        - name: second
          in: path
          required: true
          schema:
            type: string
      responses:
        '200':
          description: OK

Steps to reproduce

Run command: kiota generate --language java -n 'test'
Version: 1.10.1 (docker container mcr.microsoft.com/openapi/kiota)

Expected behaviour

client.path().byPathId("<whatever>").abc().bySecond("<something>").toGetRequestInformation().urlTemplate == "{+baseurl}/path/{path-id}/abc/{second}"

Actual behaviour

client.path().byPathId("<whatever>").abc().bySecond("<something>").toGetRequestInformation().urlTemplate == "{+baseurl}/path/{thingId}/abc/{second}"
This causes a problem because the byPathId method stores the parameter with a name of path%2Did however the url template is looking for thingId. The URL ends up with that part of the path being blank.
No errors or warnings are logged by the generator.

Workaround

Change path params to be named the same (i.e. in the above example change thingId and differentThingId to be named the same).
Of course this is only possible if you are in control of the schema in use - so in most cases this workaround won't work.

Notes

I believe this is valid OpenAPI yaml - if not please feel free to close the ticket.

There are some similar issues logged in this repo which appear to be caused by ambiguity in the URLs, however there is no ambiguity in this case, as the third part of the path is different (abc vs def).