feat(EN-994): expose v3 list-endpoint filters as typed OpenAPI components#702
feat(EN-994): expose v3 list-endpoint filters as typed OpenAPI components#702Quentin-David-24 wants to merge 3 commits into
Conversation
…ents
Each v3 list endpoint now references a per-resource V3{Resource}Filter
component listing its filterable property names with their types, and a
V3{Resource}QueryBuilder request-body wrapper that $refs it via $match.
SDK consumers get typed enums per endpoint; the frontend can introspect
the spec to discover queryable fields.
The new internal/storage/filters package is the single source of truth:
each *QueryContext switch now gates incoming keys via filters.<Spec>.Allows
and tools/compile-filters emits openapi/v3/v3-filters.generated.yaml from
the same declarations, so the storage allow-list and the OpenAPI surface
can no longer drift. Wire format is unchanged — the wrapper keeps
additionalProperties: true to preserve existing $match/$or/$and bodies.
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
| ```json | ||
| {} | ||
| { | ||
| "$match": { |
There was a problem hiding this comment.
Here's the rationale to have it like this:
OpenAPI code generators only emit types for schemas reachable from an operation (request body, response, parameter). Components that sit unused in
components/schemas are inconsistently emitted by Speakeasy — sometimes yes, sometimes no, no guarantees.
additionalProperties: true still allows to use the query DSL
There was a problem hiding this comment.
I did the test, indeed if there a components is unreachable from a path, it's not emitted and will not generate anything.
However, as we can see from the generated files, we now have a breaking change (from RequestBody to thefilter)
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #702 +/- ##
==========================================
- Coverage 65.73% 65.69% -0.04%
==========================================
Files 872 874 +2
Lines 40702 40691 -11
==========================================
- Hits 26754 26733 -21
- Misses 12210 12219 +9
- Partials 1738 1739 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
3 participants
Each v3 list endpoint now references a per-resource V3{Resource}Filter component listing its filterable property names with their types, and a V3{Resource}QueryBuilder request-body wrapper that $refs it via $match. SDK consumers get typed enums per endpoint; the frontend can introspect the spec to discover queryable fields.
The new internal/storage/filters package is the single source of truth: each *QueryContext switch now gates incoming keys via filters..Allows and tools/compile-filters emits openapi/v3/v3-filters.generated.yaml from the same declarations, so the storage allow-list and the OpenAPI surface can no longer drift. Wire format is unchanged — the wrapper keeps additionalProperties: true to preserve existing $match/$or/$and bodies.