Merged
Conversation
* adds a POST request to resources/search where you can have a more complex filter of the resources you would like to list
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 workspace-scoped POST /v1/workspaces/{workspaceId}/resources/search endpoint and a new Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant API as "API /v1/.../resources/search"
participant DB
Client->>API: POST /v1/workspaces/{workspaceId}/resources/search\n(body: ListResourcesFilters)
API->>DB: Build filtered query (workspaceId + optional filters)
API->>DB: Parallel: fetch rows (limit/offset) and count(total)
DB-->>API: rows
DB-->>API: total
API->>API: Map rows -> Resource responses
API-->>Client: 200 { items: Resource[], total, limit, offset }
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 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 |
![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: 4
🧹 Nitpick comments (2)
apps/api/openapi/schemas/resources.jsonnet (1)
134-137: Consider adding a default value forsortBy.When
sortByis omitted butorderis provided (or defaults toasc), the sort behavior becomes implementation-dependent. Adding a default likecreatedAtwould ensure predictable ordering for clients that don't explicitly specify sorting.🔧 Suggested change
sortBy: { type: 'string', enum: ['createdAt', 'updatedAt', 'name', 'kind'], + default: 'createdAt', },🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/openapi/schemas/resources.jsonnet` around lines 134 - 137, The schema for the sortBy property lacks a default, causing unpredictable sort behavior when clients omit it; update the sortBy definition (the sortBy property in resources.jsonnet) to include a default value (e.g., "createdAt") while keeping the existing enum so that when clients don't provide sortBy the API will default to predictable ordering.apps/api/openapi/openapi.json (1)
1431-1436: Consider lowering default search page size for safer baseline performance.On Line 1432,
limitdefaults to500, which is much higher than most list endpoints in this spec. A lower default (e.g.,50) reduces expensive default queries and response payload size.Suggested diff
"limit": { - "default": 500, + "default": 50, "maximum": 1000, "minimum": 1, "type": "integer" },🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/openapi/openapi.json` around lines 1431 - 1436, The OpenAPI schema's integer parameter "limit" currently has a default of 500 which is high; change the "default" value on the "limit" schema to a lower safe baseline such as 50, keeping the existing "minimum": 1 and "maximum": 1000 intact, and update any nearby docs/comments or examples that assume the 500 default to reflect the new default to avoid inconsistencies.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/api/src/routes/v1/workspaces/resources.ts`:
- Around line 367-373: The ILIKE patterns are built directly from user input
(query) in the or(...) call using ilike(schema.resource.name, `%${query}%`) and
ilike(schema.resource.identifier, `%${query}%`), which treats % and _ as SQL
wildcards; fix this by escaping backslashes, % and _ in the query before
interpolating (e.g., write a helper like escapeILikePattern(query) that replaces
"\"=>"\\" then "%"=>"\%" and "_"=>"\_"), then use the escaped value inside the
`%...%` pattern and ensure the query builder issues the ILIKE with the proper
escape character so ilike(schema.resource.name, `%${escaped}%`) and
ilike(schema.resource.identifier, `%${escaped}%`) perform literal substring
matches.
- Around line 354-355: Validate and sanitize the pagination inputs before
passing them into the query builder: for the variables declared as const limit =
body.limit and const offset = body.offset ensure they are numeric integers and
non‑negative (coerce/parse to integers or return defaults), reject or clamp
fractional/negative values (e.g., floor or error for fractions, Math.max(0,
...)), and enforce a sensible max for limit to prevent very large queries; then
pass the sanitized values to .limit() and .offset() instead of the raw body
values.
- Around line 382-405: The current ORDER BY uses only orderBy(orderFn(orderCol))
which is unstable when primary keys tie; update the query that builds the rows
to add a deterministic tiebreaker by including schema.resource.id as a secondary
sort using the same direction function (orderFn) so pagination is stable —
change the orderBy call that references orderFn(orderCol) to orderBy with two
clauses: the primary orderFn(orderCol) and a secondary
orderFn(schema.resource.id) (use the existing orderCol, orderFn identifiers and
the schema.resource.id symbol).
In `@apps/api/src/types/openapi.ts`:
- Around line 5206-5214: The OpenAPI schema for the search/list response
currently uses components["schemas"]["Resource"][] but actual responses from
toResourceResponse(...) (in apps/api/src/routes/v1/workspaces/resources.ts)
include the primary key id; update the OpenAPI source so the response items
reflect the real shape—either change the items type to the existing
ResourceResponse schema (if present) or add id:string|number to
components.schemas.Resource (or create a new ResourceResponse schema matching
toResourceResponse) so generated clients see the id property in search results.
---
Nitpick comments:
In `@apps/api/openapi/openapi.json`:
- Around line 1431-1436: The OpenAPI schema's integer parameter "limit"
currently has a default of 500 which is high; change the "default" value on the
"limit" schema to a lower safe baseline such as 50, keeping the existing
"minimum": 1 and "maximum": 1000 intact, and update any nearby docs/comments or
examples that assume the 500 default to reflect the new default to avoid
inconsistencies.
In `@apps/api/openapi/schemas/resources.jsonnet`:
- Around line 134-137: The schema for the sortBy property lacks a default,
causing unpredictable sort behavior when clients omit it; update the sortBy
definition (the sortBy property in resources.jsonnet) to include a default value
(e.g., "createdAt") while keeping the existing enum so that when clients don't
provide sortBy the API will default to predictable 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: 9b185d8f-3f97-4237-976d-acfe448948ee
📒 Files selected for processing (6)
apps/api/openapi/openapi.jsonapps/api/openapi/paths/resources.jsonnetapps/api/openapi/schemas/resources.jsonnetapps/api/src/routes/v1/workspaces/resources.tsapps/api/src/types/openapi.tspackages/workspace-engine-sdk/src/schema.ts
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/api/src/routes/v1/workspaces/resources.ts`:
- Around line 354-368: Defaults for `limit` and `offset` should be applied
before the integer validation to avoid rejecting requests where the client
omitted them; update the code that reads `const limit = body.limit; const offset
= body.offset;` to assign defaults (limit = 500, offset = 0) when those
properties are undefined (or use nullish coalescing), then run the existing
Number.isInteger and >=0 checks against those normalized values (refer to the
`limit` and `offset` variables in this file and the validation block that calls
res.status(400)).
🪄 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: 0f81b0ba-1b65-426a-83e9-b4c0a6e415ea
📒 Files selected for processing (4)
apps/api/openapi/openapi.jsonapps/api/openapi/schemas/resources.jsonnetapps/api/src/routes/v1/workspaces/resources.tsapps/api/src/types/openapi.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- apps/api/src/types/openapi.ts
- apps/api/openapi/openapi.json
jsbroks
reviewed
Apr 8, 2026
jsbroks
reviewed
Apr 8, 2026
Comment on lines
+369
to
+391
| const conditions = [eq(schema.resource.workspaceId, workspaceId)]; | ||
|
|
||
| if (providerId != null) | ||
| conditions.push(eq(schema.resource.providerId, providerId)); | ||
| if (version != null) conditions.push(eq(schema.resource.version, version)); | ||
| if (identifier != null) | ||
| conditions.push(eq(schema.resource.identifier, identifier)); | ||
| if (query != null) { | ||
| const escapedQuery = query.replace(/[%_\\]/g, "\\$&"); | ||
| conditions.push( | ||
| or( | ||
| ilike(schema.resource.name, `%${escapedQuery}%`), | ||
| ilike(schema.resource.identifier, `%${escapedQuery}%`), | ||
| )!, | ||
| ); | ||
| } | ||
| if (kinds != null && kinds.length > 0) | ||
| conditions.push(inArray(schema.resource.kind, kinds)); | ||
| if (metadata != null) { | ||
| for (const [key, value] of Object.entries(metadata)) { | ||
| conditions.push(sql`${schema.resource.metadata}->>${key} = ${value}`); | ||
| } | ||
| } |
Member
There was a problem hiding this comment.
S/TS move is usually to build the array declaratively and filter out empty entries, instead of mutating with a bunch of push calls. Essential use consts as much as possible,
You can do it:
const escapedQuery =
query != null ? query.replace(/[%_\\]/g, "\\$&") : null;
const conditions = [
eq(schema.resource.workspaceId, workspaceId),
providerId != null
? eq(schema.resource.providerId, providerId)
: undefined,
version != null
? eq(schema.resource.version, version)
: undefined,
identifier != null
? eq(schema.resource.identifier, identifier)
: undefined,
escapedQuery != null
? or(
ilike(schema.resource.name, `%${escapedQuery}%`),
ilike(schema.resource.identifier, `%${escapedQuery}%`),
)
: undefined,
kinds?.length
? inArray(schema.resource.kind, kinds)
: undefined,
...(metadata != null
? Object.entries(metadata).map(([key, value]) =>
sql`${schema.resource.metadata}->>${key} = ${value}`
)
: []),
].filter((c): c is NonNullable<typeof c> => c != null);Or in my imo
const when = <T>(condition: boolean, value: T) => (condition ? value : undefined);
const escapedQuery =
query != null ? query.replace(/[%_\\]/g, "\\$&") : null;
const conditions = [
eq(schema.resource.workspaceId, workspaceId),
when(providerId != null, eq(schema.resource.providerId, providerId)),
when(version != null, eq(schema.resource.version, version)),
when(identifier != null, eq(schema.resource.identifier, identifier)),
when(
escapedQuery != null,
or(
ilike(schema.resource.name, `%${escapedQuery}%`),
ilike(schema.resource.identifier, `%${escapedQuery}%`),
)
),
when(!!kinds?.length, inArray(schema.resource.kind, kinds!)),
...(metadata
? Object.entries(metadata).map(([key, value]) =>
sql`${schema.resource.metadata}->>${key} = ${value}`
)
: []),
].filter((c): c is NonNullable<typeof c> => c != null);
jsbroks
reviewed
Apr 8, 2026
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (1)
apps/api/src/types/openapi.ts (1)
1563-1572: Consider makingorderoptional or clarifying default sort behavior.The
orderfield is required with a default of"asc", butsortByis optional. When a client omitssortBy, the semantics oforderbecome ambiguous—what field does it apply to? Consider either:
- Making
orderoptional as well (only meaningful whensortByis provided)- Documenting the default sort field when
sortByis omittedThis is a minor API design consideration for clarity.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/types/openapi.ts` around lines 1563 - 1572, The schema currently declares order as a required field with default "asc" while sortBy is optional, making semantics unclear; update the OpenAPI type so that either (a) order becomes optional (change the "order" property to "order?: \"asc\" | \"desc\"" and remove the assumption that it always applies) OR (b) document/implement a default sort field by adding a default for sortBy (e.g., set sortBy default to "createdAt") and update the JSDoc to state that order applies to that default when sortBy is omitted; refer to the properties named order and sortBy in the same type and ensure the comment/@default annotations are adjusted accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@apps/api/src/types/openapi.ts`:
- Around line 1563-1572: The schema currently declares order as a required field
with default "asc" while sortBy is optional, making semantics unclear; update
the OpenAPI type so that either (a) order becomes optional (change the "order"
property to "order?: \"asc\" | \"desc\"" and remove the assumption that it
always applies) OR (b) document/implement a default sort field by adding a
default for sortBy (e.g., set sortBy default to "createdAt") and update the
JSDoc to state that order applies to that default when sortBy is omitted; refer
to the properties named order and sortBy in the same type and ensure the
comment/@default annotations are adjusted accordingly.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 307e98f8-a8bd-4aab-9081-fe921594e604
📒 Files selected for processing (3)
apps/api/openapi/openapi.jsonapps/api/openapi/schemas/resources.jsonnetapps/api/src/types/openapi.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- apps/api/openapi/schemas/resources.jsonnet
- apps/api/openapi/openapi.json
Co-authored-by: Justin Brooks <jsbroks@gmail.com> Signed-off-by: Mike Leone <2907207+mleonidas@users.noreply.github.com>
jsbroks
approved these changes
Apr 8, 2026
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (1)
apps/api/src/routes/v1/workspaces/resources.ts (1)
349-369:⚠️ Potential issue | 🟠 MajorAlign the local pagination guards with the documented request schema.
apps/api/openapi/schemas/resources.jsonnet:107-144documentslimitas optional with default500and range1..1000, andoffsetas optional with default0. This block validates the raw body values instead, so omitted fields still fail here,limit = 0is accepted, and oversized limits are unchecked.🛠 Proposed fix
const { providerId, version, identifier, query, kinds, - limit, - offset, + limit: rawLimit, + offset: rawOffset, metadata, sortBy, order, } = req.body; - if (!Number.isInteger(limit) || limit < 0) { - res.status(400).json({ error: "`limit` must be a non-negative integer" }); + const limit = rawLimit ?? 500; + const offset = rawOffset ?? 0; + + if (!Number.isInteger(limit) || limit < 1 || limit > 1000) { + res + .status(400) + .json({ error: "`limit` must be an integer between 1 and 1000" }); return; } if (!Number.isInteger(offset) || offset < 0) { res.status(400).json({ error: "`offset` must be a non-negative integer" });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/routes/v1/workspaces/resources.ts` around lines 349 - 369, The pagination guards in resources.ts currently validate raw req.body values and reject omitted fields; change them to apply schema defaults and enforce the documented ranges: when destructuring (providerId, version, identifier, query, kinds, limit, offset, metadata, sortBy, order) treat undefined limit as default 500 and undefined offset as default 0, then validate that limit is an integer in 1..1000 (reject 0 and >1000) and offset is an integer >= 0; update the error messages to reflect these constraints and use the normalized/filled limit and offset values for subsequent logic.
🧹 Nitpick comments (2)
apps/api/src/routes/v1/workspaces/resources.ts (2)
406-411: Keep thePromise.allbranch async/await-only.The inline
.then((r) => r[0])is the only raw promise chain in this handler. Pulling the first row out after theawaitkeeps the flow consistent and easier to scan.♻️ Proposed refactor
- const [countResult, rows] = await Promise.all([ + const [countRows, rows] = await Promise.all([ db .select({ total: count() }) .from(schema.resource) - .where(and(...conditions)) - .then((r) => r[0]), + .where(and(...conditions)), db .select() .from(schema.resource) .where(and(...conditions)) .orderBy(orderFn(orderCol), orderFn(schema.resource.identifier)) .limit(limit) .offset(offset), ]); - const total = countResult?.total ?? 0; + const total = countRows[0]?.total ?? 0;As per coding guidelines, "Prefer async/await over raw promises".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/routes/v1/workspaces/resources.ts` around lines 406 - 411, The inline .then((r) => r[0]) breaks the async/await flow; change the Promise.all branch to use only await by removing the .then and extracting the first row after awaiting the db.select call (the symbols involved are the Promise.all call, db.select({ total: count() }).from(schema.resource).where(and(...conditions)), and the variables countResult/rows). Await the select, then pull r[0] into countResult (or destructure) before continuing so the entire handler uses async/await consistently.
378-392: Plan supporting indexes for these new predicates.
packages/db/src/schema/resource.ts:48-51only indexesworkspaceIdanddeletedAt. The newILIKE(name/identifier)andmetadata->>filters will therefore scan the workspace slice, and this endpoint pays that cost twice per request (count+ page query). I’d queue a follow-up migration/query-plan check before rolling this out to large workspaces.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/routes/v1/workspaces/resources.ts` around lines 378 - 392, The new filters using ilike on schema.resource.name and schema.resource.identifier and equality on schema.resource.metadata->>key will cause full scans because only workspaceId and deletedAt are indexed; add appropriate indexes via a migration: create trigram (GIN with pg_trgm) indexes on schema.resource.name and schema.resource.identifier to support ILIKE, and add either a GIN jsonb index on schema.resource.metadata (jsonb_path_ops) or per-key btree expression indexes like ((metadata->>'yourKey')) for the specific metadata keys you expect to query; after adding indexes, run EXPLAIN on the count and page queries in apps/api/src/routes/v1/workspaces/resources.ts (where conditions.push with ilike/inArray/sql`${schema.resource.metadata}->>${key} = ${value}` is used) to verify both queries use the new indexes.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@apps/api/src/routes/v1/workspaces/resources.ts`:
- Around line 349-369: The pagination guards in resources.ts currently validate
raw req.body values and reject omitted fields; change them to apply schema
defaults and enforce the documented ranges: when destructuring (providerId,
version, identifier, query, kinds, limit, offset, metadata, sortBy, order) treat
undefined limit as default 500 and undefined offset as default 0, then validate
that limit is an integer in 1..1000 (reject 0 and >1000) and offset is an
integer >= 0; update the error messages to reflect these constraints and use the
normalized/filled limit and offset values for subsequent logic.
---
Nitpick comments:
In `@apps/api/src/routes/v1/workspaces/resources.ts`:
- Around line 406-411: The inline .then((r) => r[0]) breaks the async/await
flow; change the Promise.all branch to use only await by removing the .then and
extracting the first row after awaiting the db.select call (the symbols involved
are the Promise.all call, db.select({ total: count()
}).from(schema.resource).where(and(...conditions)), and the variables
countResult/rows). Await the select, then pull r[0] into countResult (or
destructure) before continuing so the entire handler uses async/await
consistently.
- Around line 378-392: The new filters using ilike on schema.resource.name and
schema.resource.identifier and equality on schema.resource.metadata->>key will
cause full scans because only workspaceId and deletedAt are indexed; add
appropriate indexes via a migration: create trigram (GIN with pg_trgm) indexes
on schema.resource.name and schema.resource.identifier to support ILIKE, and add
either a GIN jsonb index on schema.resource.metadata (jsonb_path_ops) or per-key
btree expression indexes like ((metadata->>'yourKey')) for the specific metadata
keys you expect to query; after adding indexes, run EXPLAIN on the count and
page queries in apps/api/src/routes/v1/workspaces/resources.ts (where
conditions.push with ilike/inArray/sql`${schema.resource.metadata}->>${key} =
${value}` is used) to verify both queries use the new indexes.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: d04e9194-d648-4ca9-8b58-daf9e8e1455f
📒 Files selected for processing (1)
apps/api/src/routes/v1/workspaces/resources.ts
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (2)
apps/api/src/types/openapi.ts (1)
5206-5207:⚠️ Potential issue | 🟠 MajorThe new search response schema still hides
id.The handler serializes rows through
toResourceResponse(...), which includes the resource primary key, but this response still advertisescomponents["schemas"]["Resource"][]. Generated clients for the new endpoint won't seeidunless the source OpenAPI schema is updated and this file is regenerated.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/types/openapi.ts` around lines 5206 - 5207, The OpenAPI schema advertised for the search response still references components["schemas"]["Resource"][] but the handler actually returns objects produced by toResourceResponse(...) which include the resource primary key (id); update the OpenAPI spec so the response schema matches the actual shape (e.g., add id to components.schemas.Resource or create a new components.schemas.ResourceWithId and use that), then regenerate the types so apps/api/src/types/openapi.ts is rebuilt and the search endpoint's response uses the corrected schema instead of components["schemas"]["Resource"][]. Ensure the change targets the operation/schema used by the new search endpoint and references the exact schema name you choose so generated clients will include id.apps/api/src/routes/v1/workspaces/resources.ts (1)
349-369:⚠️ Potential issue | 🟠 MajorNormalize pagination before validating and honor the documented bounds.
limit/offsetare read raw from the body, so omitting them still returns 400 even though the new contract defines defaults. This block also acceptslimit = 0and anything above the documented max of 1000, which lets callers bypass the API contract and issue unexpectedly large queries.🛠 Suggested fix
const { providerIds, versions, identifiers, query, kinds, - limit, - offset, metadata, sortBy, order, } = req.body; + const limit = req.body.limit ?? 500; + const offset = req.body.offset ?? 0; - if (!Number.isInteger(limit) || limit < 0) { - res.status(400).json({ error: "`limit` must be a non-negative integer" }); + if (!Number.isInteger(limit) || limit < 1 || limit > 1000) { + res + .status(400) + .json({ error: "`limit` must be an integer between 1 and 1000" }); return; } if (!Number.isInteger(offset) || offset < 0) {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/routes/v1/workspaces/resources.ts` around lines 349 - 369, Normalize pagination values from req.body before validating: if limit is undefined set it to the documented default (e.g., DEFAULT_LIMIT) and if offset is undefined set it to 0, then validate using Number.isInteger(limit) and Number.isInteger(offset) and enforce documented bounds (limit must be >= 1 and <= MAX_LIMIT (1000) and offset must be >= 0). Update the validation block around limit and offset (the variables read from req.body) to reject non-integers or out-of-range values and return clear 400 messages; introduce DEFAULT_LIMIT and MAX_LIMIT constants if not present to avoid magic numbers.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@apps/api/src/routes/v1/workspaces/resources.ts`:
- Around line 349-369: Normalize pagination values from req.body before
validating: if limit is undefined set it to the documented default (e.g.,
DEFAULT_LIMIT) and if offset is undefined set it to 0, then validate using
Number.isInteger(limit) and Number.isInteger(offset) and enforce documented
bounds (limit must be >= 1 and <= MAX_LIMIT (1000) and offset must be >= 0).
Update the validation block around limit and offset (the variables read from
req.body) to reject non-integers or out-of-range values and return clear 400
messages; introduce DEFAULT_LIMIT and MAX_LIMIT constants if not present to
avoid magic numbers.
In `@apps/api/src/types/openapi.ts`:
- Around line 5206-5207: The OpenAPI schema advertised for the search response
still references components["schemas"]["Resource"][] but the handler actually
returns objects produced by toResourceResponse(...) which include the resource
primary key (id); update the OpenAPI spec so the response schema matches the
actual shape (e.g., add id to components.schemas.Resource or create a new
components.schemas.ResourceWithId and use that), then regenerate the types so
apps/api/src/types/openapi.ts is rebuilt and the search endpoint's response uses
the corrected schema instead of components["schemas"]["Resource"][]. Ensure the
change targets the operation/schema used by the new search endpoint and
references the exact schema name you choose so generated clients will include
id.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: b0b25690-37e7-4891-bf1c-a58b44ceb9a0
📒 Files selected for processing (4)
apps/api/openapi/openapi.jsonapps/api/openapi/schemas/resources.jsonnetapps/api/src/routes/v1/workspaces/resources.tsapps/api/src/types/openapi.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/api/openapi/openapi.json
mleonidas
deleted the
920-feat-improved-api-endpoint-for-listing-resources
branch
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