feat: add filter and sort to apps

[borosr]

Add filters and sorting to the List App endpoint

What

Adds filter[*] query parameters and a sort query parameter to GET /api/v3/openmeter/apps.

Supported filters: id, name, type, status.

Supported sort fields: id, created_at (default) with optional asc/desc suffix.

Why

Callers need a way to narrow down app results without client-side filtering, e.g. finding all apps for a given type or sorted by creation time.

How

• Create the TypeSpec model with ListAppsParamsFilter and wired sort/filter query params into list
• Regenerated OpenAPI spec and Go server bindings
• Updated the HTTP handler to parse and validate filter/sort params, then pass them into ListAppsRequest
• Propagated the new fields through the service and adapter layers

---

Testing

Filter by app type:

curl -s "http://localhost:8888/api/v3/openmeter/apps?sort=created_at%20asc&filter%5Btype%5D%5Beq%5D=sandbox"

Sort by creation date descending:

curl -s  "http://localhost:8888/api/v3/openmeter/apps?sort=created_at%20asc"

Summary by CodeRabbit

• New Features

  • Apps list API supports advanced filtering (id, name, type, status) and flexible sorting (id, created_at; asc/desc).

• Improvements

  • Filter and sort query params are parsed and validated with clear per-field bad-request errors.
  • Listing logic applies structured filters and centralized ordering consistently across components.

• Tests

  • Added comprehensive tests covering filtering and sorting behaviors.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Adds API-level filtering and sorting to the apps list endpoint and wires it through spec, handler, domain types, adapters, integrations, and tests.

Changes

Apps List Filtering & Sorting

Layer / File(s)	Summary
API Specification & Contract api/spec/packages/aip/src/apps/operations.tsp	ListAppsParamsFilter model introduces optional filter fields (id, name, type, status) using common field-filter schema types. The list operation gains sort (Common.SortQuery) and filter (ListAppsParamsFilter) query parameters with deep-object encoding and documented semantics.
Domain Model - Ordering & Filtering Types openmeter/app/app.go	AppOrderBy type with validation and allowed values. ListAppInput extended with OrderBy, Order, and filter fields (ID, Name, Type, Status); Type scalar replaced by Type *filter.FilterString. Validate() validates new fields and returns a nillable aggregated validation error.
API Handler - Query Parameter Mapping api/v3/handlers/apps/list_app.go	Handler maps query parameters into ListAppsRequest using filters.FromAPIFilter* helpers for each filter field and request.ParseSortBy for sorting; parse/validation failures return BadRequest tied to the specific query parameter.
Data Adapter - Filter & Sort Application openmeter/app/adapter/app.go, openmeter/app/adapter/customer.go	App adapter applies filters via filter.ApplyToQuery and orders results using sortx/OrderBy logic. Customer adapter applies Type filtering via filter.FilterString when provided.
Comprehensive Test Coverage openmeter/app/service/list_test.go	New test suite exercises ListApps filters (ID, Name, Type, Status) and ordering (ID desc, created-at desc, default created-at asc) using a temporary Postgres-backed test service.
Integration Updates openmeter/app/sandbox/helpers.go, openmeter/billing/service/profile.go	Billing and sandbox services updated to use filter.FilterString{Eq: ...} for sandbox app type filtering instead of passing raw app type pointers.

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant HTTPHandler
  participant Filters
  participant AppService
  participant AppAdapter
  participant Database
  Client->>HTTPHandler: GET /apps?sort=...&filter[...]
  HTTPHandler->>Filters: parse filter[...] / sort
  Filters-->>HTTPHandler: parsed filter values or error
  HTTPHandler->>AppService: ListAppsRequest (filters, order)
  AppService->>AppAdapter: ListAppsRequest
  AppAdapter->>AppAdapter: apply filter.ApplyToQuery / compute order
  AppAdapter->>Database: SQL query (WHERE, ORDER BY)
  Database-->>AppAdapter: rows
  AppAdapter-->>AppService: mapped results
  AppService-->>HTTPHandler: List response
  HTTPHandler-->>Client: 200 or BadRequest

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested labels

release-note/feature

Suggested reviewers

• tothandras

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 9.09% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately captures the main change: adding filter and sort functionality to the apps list endpoint, which is the primary focus across all modified files.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/apps-v3-api-filters

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

🤖 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/apps/operations.tsp`:
- Around line 58-59: Update the filter example in the JSDoc block in
apps/operations.tsp to use the deep-object operator form instead of a plain
value; replace the current example `filter[name]=my-app` with
`filter[name][eq]=my-app` (or equivalent operator such as [contains], [ne],
etc.) so it matches the declared deep-object filter format used by the
implementation and clearly shows operator fields.

In `@openmeter/app/adapter/app.go`:
- Around line 122-126: The created_at ordering branch (case
app.AppOrderByCreatedAt in app.go) needs a stable tie-breaker so pagination is
deterministic: when applying query.Order(appdb.ByCreatedAt(order...)) also order
by a unique stable column (e.g., the primary key `id` or `uuid`) as a secondary
sort. Implement this by either extending appdb.ByCreatedAt to include the id as
a tie-breaker or by chaining another Order call (e.g., query =
query.Order(appdb.ByCreatedAt(order...)).Order(appdb.ByID(order...)) or
equivalent) so rows with equal created_at are consistently ordered.

In `@openmeter/app/service/list_test.go`:
- Line 217: The test uses require.Equal inside the assert.Eventually retry
closure which calls FailNow and breaks the retry loop; update the tests that use
assert.Eventually (the closure that checks result.TotalCount and similar
assertions) to remove any require.* calls from inside the closure, instead
return the boolean condition from the closure and then call require.Equal (or
other require.*) on result.TotalCount and the other expectations after
assert.Eventually returns true; look for usages of assert.Eventually,
require.Equal, and the result variable in this file (the assertions referencing
result.TotalCount and similar) and move the require checks out of the closure
into the code that runs after the eventual wait succeeds.

🪄 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: e85f4b45-dbe4-493f-8ae5-f0459ff2af3c

📥 Commits

Reviewing files that changed from the base of the PR and between daa002d and 2d730df.

⛔ Files ignored due to path filters (1)

• api/v3/openapi.yaml is excluded by !**/openapi.yaml

📒 Files selected for processing (9)

• api/spec/packages/aip/src/apps/operations.tsp
• api/v3/api.gen.go
• api/v3/handlers/apps/list_app.go
• openmeter/app/adapter/app.go
• openmeter/app/adapter/customer.go
• openmeter/app/app.go
• openmeter/app/sandbox/helpers.go
• openmeter/app/service/list_test.go
• openmeter/billing/service/profile.go