Limit add_operation_fields to fields that are expected to contain an Operation object

[micolous]

Description

The add_operation_fields setting currently applies changes to all Path Item fields, not just those that are expected to contain an Operation object.

One way this can fail is if you pass the parameters field on the Path Item object, rather than the Operation object itself, eg:

paths:
  /pets/{petId}:
    parameters:
      - name: petId
        in: path
        required: true
        description: The id of the pet to retrieve
        schema:
          type: string
    get:
      summary: Info for a specific pet
      operationId: showPetById
      # ...

This schema then fails to load:

Traceback (most recent call last):
  File ".../app.py", line 9, in <module>
    app = foca.create_app()
          ^^^^^^^^^^^^^^^^^
  File ".../.venv/lib/python3.12/site-packages/foca/foca.py", line 110, in create_app
    cnx_app = register_openapi(
              ^^^^^^^^^^^^^^^^^
  File ".../.venv/lib/python3.12/site-packages/foca/api/register_openapi.py", line 57, in register_openapi
    operation_object[key] = val
    ~~~~~~~~~~~~~~~~^^^^^
TypeError: list indices must be integers or slices, not str

This fixes the issue by limiting add_operation_fields to just fields which are expected to contain Operation objects (ie: HTTP verbs).

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have updated the documentation (or documentation does not need to be updated)
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have not reduced the existing code coverage

Summary by Sourcery

Limit the 'add_operation_fields' setting to only apply changes to fields expected to contain Operation objects, resolving a TypeError when non-Operation fields are modified. Add a test case to ensure correct behavior with PathItem.parameters field.

Bug Fixes:

• Fix the issue where the 'add_operation_fields' setting incorrectly applied changes to all Path Item fields, by limiting it to fields expected to contain Operation objects (i.e., HTTP verbs).

Tests:

• Add a test case to verify the correct registration of OpenAPI 3 YAML specs with PathItem.parameters field using Connexion app.

[sourcery-ai]

Reviewer's Guide by Sourcery

This PR fixes a bug in the OpenAPI specification handling where the add_operation_fields setting was incorrectly being applied to all Path Item fields instead of only Operation objects (HTTP verbs). The implementation adds a check to ensure that operation fields are only added to valid HTTP verb fields (GET, POST, PUT, etc.).

Class diagram for register_openapi function changes

classDiagram
    class register_openapi {
        +register_openapi(app: App, specs: List[SpecConfig])
    }
    class SpecConfig {
        +path: Path
        +path_out: Path
        +append: List
        +add_operation_fields: Dict
        +add_security_fields: Dict
        +disable_auth: bool
        +connexion: ConnexionConfig
    }
    class App {
        +App(name: str)
    }
    class ConnexionConfig

    register_openapi --> SpecConfig
    register_openapi --> App
    SpecConfig --> ConnexionConfig

    note for register_openapi "Now checks if operation is in _OPERATION_OBJECT_FIELDS before adding fields"

Loading

File-Level Changes

Change	Details	Files
Added validation for Operation object fields	Defined a frozen set of valid HTTP verbs that can contain Operation objects Added a condition to skip non-Operation fields when applying operation fields Updated the operation field application loop to check field names	foca/api/register_openapi.py
Added test coverage for Path Item parameters	Created new test case for OpenAPI 3 specs with PathItem.parameters field Added test configuration for path item parameter testing Added test YAML files for path item parameter scenarios	tests/api/test_register_openapi.py tests/test_files/openapi_3_petstore_pathitemparam.original.yaml tests/test_files/openapi_3_petstore_pathitemparam.modified.yaml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time. You can also use
  this command to specify where the summary should be inserted.

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey @micolous - I've reviewed your changes and they look great!

Here's what I looked at during the review

• 🟢 General issues: all looks good
• 🟢 Security: all looks good
• 🟡 Testing: 1 issue found
• 🟢 Complexity: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}