feat: add plan addon filters#4366
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds deepObject-style filtering and sort support to ListPlanAddons: API contract and generated types, handler binding and validation, service input typed filters and validation, adapter predicate construction using filter helpers, and updated tests. ChangesListPlanAddons Filter & Sort Implementation
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
7da7fd2 to
b411e6d
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
openmeter/productcatalog/planaddon/service/service_test.go (1)
396-416: ⚡ Quick winSort tests don’t currently prove sorting behavior.
Right now these checks only assert non-empty results, so they can pass even if ordering is wrong. Please add at least two plan-addon assignments with distinct
created_at/idand assert relative order in the returned list.As per coding guidelines: “Make sure the tests are comprehensive and cover the changes. Keep a strong focus on unit tests and in-code integration tests.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@openmeter/productcatalog/planaddon/service/service_test.go` around lines 396 - 416, The two sort tests (SortByCreatedAtDesc and SortByID) only assert non-empty results; create two distinct plan-addon records before each test (use env.PlanAddon.CreatePlanAddon or the test fixture helper) with different created_at timestamps and/or IDs, then call env.PlanAddon.ListPlanAddons with ListPlanAddonsInput (OrderByCreatedAt/OrderByID and OrderDesc/OrderAsc) and assert the returned Items are ordered by comparing Items[0].ID vs Items[1].ID or Items[0].CreatedAt vs Items[1].CreatedAt as appropriate; keep this setup and assertions inside the existing t.Run blocks to ensure the tests validate ordering.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@api/spec/packages/aip/src/productcatalog/operations.tsp`:
- Line 293: Remove the plan_id filter field from the filter model: delete the
"plan_id?: Common.ULIDFieldFilter;" entry so the TypeSpec model no longer
advertises filter[plan_id]; this ensures the model matches runtime behavior
where planId is provided via the path parameter. Update any related model/type
declarations that reference this field (and associated docs/tests) to avoid
exposing or validating plan_id in the filter. Ensure compilation/typechecks pass
after removing the field.
---
Nitpick comments:
In `@openmeter/productcatalog/planaddon/service/service_test.go`:
- Around line 396-416: The two sort tests (SortByCreatedAtDesc and SortByID)
only assert non-empty results; create two distinct plan-addon records before
each test (use env.PlanAddon.CreatePlanAddon or the test fixture helper) with
different created_at timestamps and/or IDs, then call
env.PlanAddon.ListPlanAddons with ListPlanAddonsInput
(OrderByCreatedAt/OrderByID and OrderDesc/OrderAsc) and assert the returned
Items are ordered by comparing Items[0].ID vs Items[1].ID or Items[0].CreatedAt
vs Items[1].CreatedAt as appropriate; keep this setup and assertions inside the
existing t.Run blocks to ensure the tests validate ordering.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: c3685fee-aac8-4a51-8c0c-0393da3f779b
⛔ Files ignored due to path filters (1)
api/v3/openapi.yamlis excluded by!**/openapi.yaml
📒 Files selected for processing (9)
api/spec/packages/aip/src/productcatalog/operations.tspapi/v3/api.gen.goapi/v3/handlers/plans/planaddons/lists.goopenmeter/productcatalog/planaddon/adapter/adapter_test.goopenmeter/productcatalog/planaddon/adapter/planaddon.goopenmeter/productcatalog/planaddon/httpdriver/planaddon.goopenmeter/productcatalog/planaddon/service.goopenmeter/productcatalog/planaddon/service/service_test.gopkg/filter/filter.go
Add filters and sorting to the List Plan Addons endpoint
What
Adds
filter[*]query parameters and asortquery parameter toGET /api/v3/plans/{planId}/addons.Supported filters:
id,plan_key,addon_id,addon_key,addon_name,plan_currency(passingfilter[plan_id]is rejected since the plan is already scoped via the path parameter).Supported sort fields:
id(default),created_at,updated_at, with optionalasc/descsuffix.Why
Callers need a way to narrow down plan addon results without client-side filtering, e.g. finding all addons for a given currency or sorted by creation time.
How
ListPlanAddonsParamsFilterand wiredsort/filterquery params intolistPlanAddonsListPlanAddonsRequestTesting
Filter by addon key:
curl -s "http://localhost:8888/api/v3/plans/01HX.../addons?filter[addon_key]=storage-addon"Sort by creation date descending:
Summary by CodeRabbit
New Features
Bug Fixes / Behavior
Tests