Merged
Conversation
Contributor
|
Note Reviews pausedIt 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 Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds a MeterQuery feature (new query models + POST /meters/{meterId} endpoint), refactors shared filter models from Metering* → QueryFilter*, updates a field-prefix lint rule to exclude specific prefixes, and removes related suppression directives in two spec files. Generated Go server types and a route handler stub were added. Changes
Sequence DiagramsequenceDiagram
participant Client as Client
participant API as "Router / API Gateway"
participant Handler as "Server Handler (QueryMeter)"
participant Store as "Meter Store / DB"
Client->>API: POST /openmeter/meters/{meterId} (MeterQueryRequest)
API->>Handler: invoke QueryMeter(meterId, request)
Handler->>Store: execute query(filters, time range, group_by, granularity)
Store->>Store: aggregate/window data
Store-->>Handler: return MeterQueryRow[]
Handler-->>API: return MeterQueryResult
API-->>Client: 200 OK + MeterQueryResult
Estimated code review effort🎯 5 (Critical) | ⏱️ ~120 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
api/spec/src/v3/meters/query.tsp (1)
156-158: Consider tighteningcustomer_idtoShared.ULID.Using plain
stringhere drops identifier-format validation for a field that appears to be a customer ID.💡 Suggested spec tweak
- customer_id?: string; + customer_id?: Shared.ULID;As per coding guidelines: "The declared API should be accurate, in parity with the actual implementation, and easy to understand for the user."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api/spec/src/v3/meters/query.tsp` around lines 156 - 158, The customer_id field is declared as a plain string which bypasses ULID validation; update the type annotation for customer_id from string to Shared.ULID in the meters query spec so the schema enforces the ULID format (locate the customer_id property in the query type/interface definition in api/spec/src/v3/meters/query.tsp and change its type to Shared.ULID).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@api/v3/server/routes.go`:
- Around line 29-31: The handler QueryMeter currently delegates to
unimplemented.QueryMeter and must be wired to the server's actual meter logic:
replace the call to unimplemented.QueryMeter in func (s *Server) QueryMeter(w
http.ResponseWriter, r *http.Request, meterId api.ULID) with code that uses the
Server's meter service/store (e.g., s.MeterStore, s.MeterService, or whatever
central type on Server holds meter logic) to perform the query using the
provided meterId, handle request body/params if the endpoint expects a POST
payload, marshal the result to JSON and write it to w with the appropriate
status (200 on success), and return proper error responses and status codes on
not-found or failure (including logging). Ensure you reference and call the
concrete method on the server's meter component (e.g., MeterService.QueryMeter
or MeterStore.GetMeter) and not unimplemented.QueryMeter so the POST
/openmeter/meters/{meterId} endpoint becomes functional.
---
Nitpick comments:
In `@api/spec/src/v3/meters/query.tsp`:
- Around line 156-158: The customer_id field is declared as a plain string which
bypasses ULID validation; update the type annotation for customer_id from string
to Shared.ULID in the meters query spec so the schema enforces the ULID format
(locate the customer_id property in the query type/interface definition in
api/spec/src/v3/meters/query.tsp and change its type to Shared.ULID).
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
api/v3/openapi.yamlis excluded by!**/openapi.yaml
📒 Files selected for processing (8)
api/spec/lib/rules/field-prefix.jsapi/spec/src/v3/apps/external_invoicing.tspapi/spec/src/v3/customers/billing.tspapi/spec/src/v3/meters/operations.tspapi/spec/src/v3/meters/query.tspapi/spec/src/v3/shared/filters.tspapi/v3/api.gen.goapi/v3/server/routes.go
💤 Files with no reviewable changes (2)
- api/spec/src/v3/customers/billing.tsp
- api/spec/src/v3/apps/external_invoicing.tsp
tothandras
force-pushed
the
feat/api-v3-query-meter
branch
from
ae64bf7 to
850bdcf
Compare
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (1)
api/spec/src/v3/shared/filters.tsp (1)
127-166: ConsolidateQueryFilterFloatandQueryFilterNumericto useShared.Numeric
QueryFilterFloatandQueryFilterNumerichave identical structure but different types—float64vs.Shared.Numeric. SinceShared.Numericis the project standard for arbitrary-precision numeric values (andMoneyis aliased to it), usingfloat64risks precision drift and creates unnecessary API surface confusion. Either consolidate to a single filter usingShared.Numeric, or deprecateQueryFilterFloat.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api/spec/src/v3/shared/filters.tsp` around lines 127 - 166, QueryFilterFloat currently uses float64 and duplicates QueryFilterNumeric; replace all float64 usages in the QueryFilterFloat model (gt, gte, lt, lte) with Shared.Numeric and keep the and?: QueryFilterFloat[] and or?: QueryFilterFloat[] so the model aligns with the project-wide numeric type (Shared.Numeric) and avoids precision drift/API duplication; alternatively, remove QueryFilterFloat and update callers to use QueryFilterNumeric if you prefer full consolidation.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@api/spec/src/v3/shared/filters.tsp`:
- Around line 127-166: QueryFilterFloat currently uses float64 and duplicates
QueryFilterNumeric; replace all float64 usages in the QueryFilterFloat model
(gt, gte, lt, lte) with Shared.Numeric and keep the and?: QueryFilterFloat[] and
or?: QueryFilterFloat[] so the model aligns with the project-wide numeric type
(Shared.Numeric) and avoids precision drift/API duplication; alternatively,
remove QueryFilterFloat and update callers to use QueryFilterNumeric if you
prefer full consolidation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 3d493f35-d5bc-4fb0-8d66-c2d4d7e28199
⛔ Files ignored due to path filters (1)
api/v3/openapi.yamlis excluded by!**/openapi.yaml
📒 Files selected for processing (8)
api/spec/lib/rules/field-prefix.jsapi/spec/src/v3/apps/external_invoicing.tspapi/spec/src/v3/customers/billing.tspapi/spec/src/v3/meters/operations.tspapi/spec/src/v3/meters/query.tspapi/spec/src/v3/shared/filters.tspapi/v3/api.gen.goapi/v3/server/routes.go
💤 Files with no reviewable changes (2)
- api/spec/src/v3/apps/external_invoicing.tsp
- api/spec/src/v3/customers/billing.tsp
🚧 Files skipped from review as they are similar to previous changes (4)
- api/v3/server/routes.go
- api/spec/src/v3/meters/query.tsp
- api/spec/lib/rules/field-prefix.js
- api/spec/src/v3/meters/operations.tsp
tothandras
force-pushed
the
feat/api-v3-query-meter
branch
from
850bdcf to
9c911ff
Compare
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
api/spec/src/v3/shared/filters.tsp (1)
153-173: PreferShared.Numericoverfloat64inQueryFilterFloat.Using binary floats in API filter inputs can introduce precision drift across clients/backends. Switching to
Shared.Numerickeeps behavior aligned with the rest of the precision-safe numeric surface.💡 Suggested change
model QueryFilterFloat { /** * The attribute is greater than the provided value. */ - gt?: float64; + gt?: Shared.Numeric; /** * The attribute is greater than or equal to the provided value. */ - gte?: float64; + gte?: Shared.Numeric; /** * The attribute is less than the provided value. */ - lt?: float64; + lt?: Shared.Numeric; /** * The attribute is less than or equal to the provided value. */ - lte?: float64; + lte?: Shared.Numeric;Based on learnings: "prefer using Shared.Numeric ... broadly to all TypeSpec files under api/spec to ensure consistent precision handling and serialization."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api/spec/src/v3/shared/filters.tsp` around lines 153 - 173, The QueryFilterFloat model uses float64 for gt, gte, lt, and lte which can cause precision drift; update the type of those properties to Shared.Numeric instead to match the precision-safe numeric surface used elsewhere. Locate the QueryFilterFloat model and replace each float64 occurrence for gt, gte, lt, and lte with Shared.Numeric, and ensure any necessary references/imports to Shared.Numeric are present so the model compiles and serializes consistently with other API specs.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@api/spec/src/v3/meters/query.tsp`:
- Line 23: The filters.dimensions property (currently typed as dimensions?:
Shared.QueryFilterStringMap) is unbounded and should be capped like
group_by_dimensions to avoid oversized payloads; update the type of dimensions
(or the surrounding interface) to enforce a maximum number of keys (the same
hard cap used by group_by_dimensions) and validate/reflect this constraint in
the type definition and any runtime validation code that constructs or accepts
the query (reference the symbols dimensions, filters.dimensions,
Shared.QueryFilterStringMap and group_by_dimensions when making the change).
In `@api/spec/src/v3/shared/filters.tsp`:
- Around line 67-79: QueryFilterStringMapItem currently spreads
...QueryFilterString which defines and/or as QueryFilterString[], causing nested
clauses to lose the map-item-specific flags (exists/nexists); modify the schema
so the recursive branches reference the map-item shape instead of
QueryFilterString — e.g., make and and or on QueryFilterStringMapItem typed as
QueryFilterStringMapItem[] (or replace the spread with an explicit
self-recursive definition) so exists and nexists remain available inside nested
and/or; update the definition of QueryFilterStringMapItem (and remove or adjust
the ...QueryFilterString spread) to enforce this recursive map-item type.
---
Nitpick comments:
In `@api/spec/src/v3/shared/filters.tsp`:
- Around line 153-173: The QueryFilterFloat model uses float64 for gt, gte, lt,
and lte which can cause precision drift; update the type of those properties to
Shared.Numeric instead to match the precision-safe numeric surface used
elsewhere. Locate the QueryFilterFloat model and replace each float64 occurrence
for gt, gte, lt, and lte with Shared.Numeric, and ensure any necessary
references/imports to Shared.Numeric are present so the model compiles and
serializes consistently with other API specs.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: f3912450-fbb9-4fff-8a7e-0e0165e81a1b
⛔ Files ignored due to path filters (1)
api/v3/openapi.yamlis excluded by!**/openapi.yaml
📒 Files selected for processing (8)
api/spec/lib/rules/field-prefix.jsapi/spec/src/v3/apps/external_invoicing.tspapi/spec/src/v3/customers/billing.tspapi/spec/src/v3/meters/operations.tspapi/spec/src/v3/meters/query.tspapi/spec/src/v3/shared/filters.tspapi/v3/api.gen.goapi/v3/server/routes.go
💤 Files with no reviewable changes (2)
- api/spec/src/v3/customers/billing.tsp
- api/spec/src/v3/apps/external_invoicing.tsp
🚧 Files skipped from review as they are similar to previous changes (3)
- api/v3/server/routes.go
- api/spec/src/v3/meters/operations.tsp
- api/spec/lib/rules/field-prefix.js
tothandras
force-pushed
the
feat/api-v3-query-meter
branch
from
9c911ff to
e40e6a7
Compare
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
api/spec/src/v3/meters/query.tsp (1)
23-23:⚠️ Potential issue | 🟠 MajorPlease cap
filters.dimensionssize.Line 23 is currently unbounded. A large dimensions object can create expensive query plans and oversized payloads.
💡 Suggested change
model MeterQueryFilters { /** * Filters to apply to the dimensions of the query. */ + `@maxProperties`(100) dimensions?: Shared.QueryFilterStringMap; }As per coding guidelines: "The declared API should be accurate, in parity with the actual implementation, and easy to understand for the user."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api/spec/src/v3/meters/query.tsp` at line 23, The dimensions property currently typed as Shared.QueryFilterStringMap is unbounded; add a bounded variant (e.g., Shared.QueryFilterStringMapLimited or DimensionsLimited) and change the declaration from dimensions?: Shared.QueryFilterStringMap to dimensions?: Shared.QueryFilterStringMapLimited with a documented max entries limit (suggest 50). Also add runtime validation where the meters query payload is processed (the request validator / handler that reads filters.dimensions) to reject requests exceeding the max with a clear error. Update any related schema/typing helpers and tests to use the new Limited type and validation rule so the API surface and implementation stay in parity.api/spec/src/v3/shared/filters.tsp (1)
67-79:⚠️ Potential issue | 🟠 Major
QueryFilterStringMapItemloses map-item semantics in nestedand/or.Because Line 78 spreads
QueryFilterString, nestedand/orare typed asQueryFilterString[], so nested clauses cannot carryexists/nexists.💡 Suggested shape (self-recursive map-item branches)
model QueryFilterStringMapItem { /** * The attribute exists. */ exists?: boolean; /** * The attribute does not exist. */ nexists?: boolean; - ...QueryFilterString; + eq?: string; + neq?: string; + `@minItems`(1) + `@maxItems`(100) + in?: string[]; + `@minItems`(1) + `@maxItems`(100) + nin?: string[]; + contains?: string; + ncontains?: string; + + `@minItems`(1) + `@maxItems`(10) + and?: QueryFilterStringMapItem[]; + + `@minItems`(1) + `@maxItems`(10) + or?: QueryFilterStringMapItem[]; }#!/bin/bash # Verify generated recursion shape from the spec. rg -n -C2 'type QueryFilterStringMapItem struct|And \*\[\]QueryFilterString|Or \*\[\]QueryFilterString' api/v3/api.gen.goAs per coding guidelines: "The declared API should be accurate, in parity with the actual implementation, and easy to understand for the user."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api/spec/src/v3/shared/filters.tsp` around lines 67 - 79, QueryFilterStringMapItem currently spreads QueryFilterString which makes nested and/or resolve to QueryFilterString[] and lose the map-item fields (exists/nexists); change the schema so QueryFilterStringMapItem retains its own fields and makes the logical branches self-recursive (i.e., define and and or on QueryFilterStringMapItem as arrays of QueryFilterStringMapItem or otherwise replace the spread of QueryFilterString with an explicit merge that sets and?: QueryFilterStringMapItem[] and or?: QueryFilterStringMapItem[] while preserving all QueryFilterString properties, ensuring nested clauses keep exists/nexists; update any related type aliases that reference QueryFilterString to accept this recursive map-item shape.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@api/spec/src/v3/shared/filters.tsp`:
- Line 21: The generated API types are out of sync with the TypeSpec changes:
the spec now defines filters containing the fields `contains` and `ncontains` in
filters.tsp but the generated types still expose the legacy `Like` and `Nlike`
fields; update the code generation or mapping so the generated models use
`contains` and `ncontains` instead of `Like`/`Nlike`. Locate the filter type
declarations (e.g., the filter interface/type that currently includes `Like` and
`Nlike`) and modify the generator/templates or transformation step to emit
`contains?: string` and `ncontains?: string` (and remove `Like`/`Nlike`), then
re-run the TypeSpec generation to ensure the API types match the spec (also
apply the same fix to the other affected declarations referenced around the
block that includes lines 40–45).
In `@api/v3/api.gen.go`:
- Around line 3938-3942: Add a short explanatory comment above the
Unimplemented.QueryMeter handler stating that the POST
/openmeter/meters/{meterId} endpoint is intentionally left as a 501 stub while
the v3 feature is scaffolded and that routes delegate to
unimplemented.QueryMeter until a full implementation is added; reference the
Unimplemented.QueryMeter function name and note that this is deliberate to avoid
the handler being mistaken for an accidental omission.
---
Duplicate comments:
In `@api/spec/src/v3/meters/query.tsp`:
- Line 23: The dimensions property currently typed as
Shared.QueryFilterStringMap is unbounded; add a bounded variant (e.g.,
Shared.QueryFilterStringMapLimited or DimensionsLimited) and change the
declaration from dimensions?: Shared.QueryFilterStringMap to dimensions?:
Shared.QueryFilterStringMapLimited with a documented max entries limit (suggest
50). Also add runtime validation where the meters query payload is processed
(the request validator / handler that reads filters.dimensions) to reject
requests exceeding the max with a clear error. Update any related schema/typing
helpers and tests to use the new Limited type and validation rule so the API
surface and implementation stay in parity.
In `@api/spec/src/v3/shared/filters.tsp`:
- Around line 67-79: QueryFilterStringMapItem currently spreads
QueryFilterString which makes nested and/or resolve to QueryFilterString[] and
lose the map-item fields (exists/nexists); change the schema so
QueryFilterStringMapItem retains its own fields and makes the logical branches
self-recursive (i.e., define and and or on QueryFilterStringMapItem as arrays of
QueryFilterStringMapItem or otherwise replace the spread of QueryFilterString
with an explicit merge that sets and?: QueryFilterStringMapItem[] and or?:
QueryFilterStringMapItem[] while preserving all QueryFilterString properties,
ensuring nested clauses keep exists/nexists; update any related type aliases
that reference QueryFilterString to accept this recursive map-item shape.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 17add27c-5bd5-4248-bd1b-207a2adb6b5e
⛔ Files ignored due to path filters (1)
api/v3/openapi.yamlis excluded by!**/openapi.yaml
📒 Files selected for processing (8)
api/spec/lib/rules/field-prefix.jsapi/spec/src/v3/apps/external_invoicing.tspapi/spec/src/v3/customers/billing.tspapi/spec/src/v3/meters/operations.tspapi/spec/src/v3/meters/query.tspapi/spec/src/v3/shared/filters.tspapi/v3/api.gen.goapi/v3/server/routes.go
💤 Files with no reviewable changes (2)
- api/spec/src/v3/customers/billing.tsp
- api/spec/src/v3/apps/external_invoicing.tsp
🚧 Files skipped from review as they are similar to previous changes (1)
- api/v3/server/routes.go
Comment on lines
+3938
to
+3942
| // Query meter | ||
| // (POST /openmeter/meters/{meterId}) | ||
| func (_ Unimplemented) QueryMeter(w http.ResponseWriter, r *http.Request, meterId ULID) { | ||
| w.WriteHeader(http.StatusNotImplemented) | ||
| } |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Search for all QueryMeter function implementations
find . -type f -name "*.go" | head -20
rg -n --type=go "QueryMeter" | head -30Repository: openmeterio/openmeter
Length of output: 4232
🏁 Script executed:
# Look for the ServerInterface and concrete implementations
rg -n --type=go "type.*ServerInterface" -A 5 | head -50Repository: openmeterio/openmeter
Length of output: 1370
🏁 Script executed:
# Check for route registration and handler setup
rg -n --type=go "openmeter/meters" | head -20Repository: openmeterio/openmeter
Length of output: 1114
🏁 Script executed:
# Look for the unimplemented pattern and how it's handled
rg -n --type=go "Unimplemented" -A 2 | head -40Repository: openmeterio/openmeter
Length of output: 1918
🏁 Script executed:
# Look at the Router struct and see what methods it implements
rg -n --type=go "type Router struct" -A 20 openmeter/server/router/
# Look at the meter.go file to see QueryMeter implementations
cat -n openmeter/server/router/meter.go | head -75Repository: openmeterio/openmeter
Length of output: 5066
🏁 Script executed:
# Check if Router implements the ServerInterface by looking for all its methods
rg -n --type=go "^func \(a \*Router\)" openmeter/server/router/meter.goRepository: openmeterio/openmeter
Length of output: 1047
🏁 Script executed:
# See the actual wrapper delegation pattern
sed -n '4041,4100p' api/v3/api.gen.goRepository: openmeterio/openmeter
Length of output: 1987
🏁 Script executed:
# Check the v3/server/routes.go file
cat -n api/v3/server/routes.go | head -50Repository: openmeterio/openmeter
Length of output: 1886
🏁 Script executed:
# Look for ServerInterface implementations
rg -n --type=go "func \(.*\) QueryMeter\(" | grep -v "streaming"Repository: openmeterio/openmeter
Length of output: 1092
🏁 Script executed:
# Check if Router is used for v3
rg -n --type=go "api\.NewServerInterfaceToHandlerWithOptions|api\.Unimplemented" api/v3/Repository: openmeterio/openmeter
Length of output: 130
🏁 Script executed:
# Check if there are any TODOs or comments around the QueryMeter implementation
sed -n '25,35p' api/v3/server/routes.goRepository: openmeterio/openmeter
Length of output: 440
🏁 Script executed:
# Check git to see when this was added or if there are related comments
git log --oneline -20 -- api/v3/server/routes.go 2>/dev/null || echo "Git history not available"Repository: openmeterio/openmeter
Length of output: 99
QueryMeter (POST /openmeter/meters/{meterId}) is intentionally stubbed to return 501.
The endpoint is wired and routed, but api/v3/server/routes.go:29–31 explicitly delegates to unimplemented.QueryMeter(). Since this is scaffolding for the v3 feature, consider adding a brief comment documenting that the handler implementation is pending—just so future devs (and your future self) know this is intentional and not forgotten.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@api/v3/api.gen.go` around lines 3938 - 3942, Add a short explanatory comment
above the Unimplemented.QueryMeter handler stating that the POST
/openmeter/meters/{meterId} endpoint is intentionally left as a 501 stub while
the v3 feature is scaffolded and that routes delegate to
unimplemented.QueryMeter until a full implementation is added; reference the
Unimplemented.QueryMeter function name and note that this is deliberate to avoid
the handler being mistaken for an accidental omission.
hekike
reviewed
Mar 5, 2026
tothandras
force-pushed
the
feat/api-v3-query-meter
branch
from
e40e6a7 to
bfe972b
Compare
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@api/spec/src/v3/meters/query.tsp`:
- Around line 20-21: The Hour granularity literal is using a non-standard
ISO-8601 token "P1H"; update the literal for the Hour enum/constant (symbol:
Hour) to the correct ISO-8601 duration "PT1H" so parsers/clients receive the
proper one-hour duration value and maintain compatibility.
- Around line 42-51: The JSDoc for subject_key and customer_id claims only
"eq"/"in" are supported, but their type Shared.QueryFilterString includes
additional operators; fix by aligning the schema and docs: either narrow the
property types (e.g., introduce and use a Dedicated type that only allows eq/in,
such as QueryFilterStringEqIn) for subject_key and customer_id, or expand the
doc to enumerate all supported operators and behaviors exposed by
Shared.QueryFilterString; update references to Shared.QueryFilterString,
subject_key, and customer_id so the declared type and the comment are
consistent.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: dcf394c3-1eec-4b0d-9b80-8516f5355854
⛔ Files ignored due to path filters (2)
api/spec/pnpm-lock.yamlis excluded by!**/pnpm-lock.yamlapi/v3/openapi.yamlis excluded by!**/openapi.yaml
📒 Files selected for processing (9)
api/spec/lib/rules/field-prefix.jsapi/spec/package.jsonapi/spec/src/v3/apps/external_invoicing.tspapi/spec/src/v3/customers/billing.tspapi/spec/src/v3/meters/operations.tspapi/spec/src/v3/meters/query.tspapi/spec/src/v3/shared/filters.tspapi/v3/api.gen.goapi/v3/server/routes.go
💤 Files with no reviewable changes (2)
- api/spec/src/v3/customers/billing.tsp
- api/spec/src/v3/apps/external_invoicing.tsp
🚧 Files skipped from review as they are similar to previous changes (4)
- api/spec/src/v3/meters/operations.tsp
- api/spec/src/v3/shared/filters.tsp
- api/spec/lib/rules/field-prefix.js
- api/v3/server/routes.go
tothandras
force-pushed
the
feat/api-v3-query-meter
branch
from
f4a0f9f to
28b265d
Compare
hekike
approved these changes
Mar 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
New Features
Refactor
Bug Fixes
Chores