Skip to content

Validate OpenAPI spec payloads#51

Open
bernardassistant557-arch wants to merge 1 commit intodatagouv:mainfrom
bernardassistant557-arch:main
Open

Validate OpenAPI spec payloads#51
bernardassistant557-arch wants to merge 1 commit intodatagouv:mainfrom
bernardassistant557-arch:main

Conversation

@bernardassistant557-arch
Copy link
Copy Markdown

@bernardassistant557-arch bernardassistant557-arch commented Feb 28, 2026

Summary

  • ensure OpenAPI spec parsing only returns mapping objects
  • raise a clear error when the spec payload isn't a JSON/YAML object
  • add a unit test that covers the invalid-body case

Problem

fetch_openapi_spec would happily return non-dict payloads (e.g., a plain string), which makes downstream usage fail later and produces confusing errors.

Reasoning

OpenAPI specs are defined as JSON/YAML objects. Enforcing that early keeps behavior predictable and surfaces bad specs immediately.

Changes

  • validate parsed JSON/YAML is a dict before returning
  • tighten the error message when parsing fails
  • add a MockTransport test to guard against non-dict specs

Testing

  • uv run pytest tests/test_datagouv_api.py (fails locally: uv not installed)

Copy link
Copy Markdown
Collaborator

@bolinocroustibat bolinocroustibat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for tightening the contract by only accepting a top-level object (dict) and adding a test for a 200 + non-spec body.

Could you provide an example when this happens?

Also, please solve the merge conflict with main branch.


raise ValueError(f"Could not parse OpenAPI spec from {url} as JSON or YAML")
raise ValueError(
f"Could not parse OpenAPI spec from {url} as JSON or YAML object"
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's keep a single-line raise to avoid unrelated formatting in the PR.

@bolinocroustibat bolinocroustibat added 3 - Low priority Nice-to-have question Further information is requested labels Apr 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

3 - Low priority Nice-to-have question Further information is requested

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants