Conversation
|
Note
|
| Cohort / File(s) | Summary |
|---|---|
Contract Type Definitions packages/app/api-contracts/src/sse/dualModeContracts.ts, packages/app/api-contracts/src/sse/sseContracts.ts |
Extended DualModeContractDefinition, AnyDualModeContractDefinition, SSEContractDefinition, and AnySSEContractDefinition with optional metadata, description, summary, and tags fields. Updated imports to include CommonRouteDefinitionMetadata. |
Builder Implementation packages/app/api-contracts/src/sse/sseContractBuilders.ts |
Added metadata, description, summary, and tags fields to SSEGetContractConfig, SSEPayloadContractConfig, DualModeGetContractConfig, and DualModePayloadContractConfig. Updated buildBaseFields to propagate these properties into generated contract definitions. |
Builder Tests packages/app/api-contracts/src/sse/sseContractBuilders.metadata.spec.ts |
New comprehensive test suite validating metadata augmentation for all route modes (GET, POST, dual-mode GET, dual-mode POST), including module augmentation of CommonRouteDefinitionMetadata with test properties. |
Estimated code review effort
🎯 3 (Moderate) | ⏱️ ~20 minutes
🚥 Pre-merge checks | ✅ 1 | ❌ 2
❌ Failed checks (1 warning, 1 inconclusive)
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Description check | The PR description is largely incomplete, with only checklist items checked but no substantive content under the 'Changes' section explaining what fields were added or why. | Fill out the 'Changes' section with details about which SSE types now include metadata, description, summary, and tags fields, and explain the purpose of these additions. | |
| Title check | ❓ Inconclusive | The title 'Adding missing fields to SSE' is vague and generic, using non-descriptive language that doesn't convey which specific fields are being added or why. | Replace with a more specific title like 'Add metadata, description, summary, and tags fields to SSE contract definitions' to clearly indicate the exact changes made. |
✅ Passed checks (1 passed)
| Check name | Status | Explanation |
|---|---|---|
| Docstring Coverage | ✅ Passed | Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. |
✏️ Tip: You can configure your own custom pre-merge checks in the settings.
✨ Finishing Touches
- 📝 Generate docstrings (stacked PR)
- 📝 Generate docstrings (commit on current branch)
🧪 Generate unit tests (beta)
- Create PR with unit tests
- Post copyable unit tests in a comment
- Commit unit tests in branch
feat/api-contracts_sse_metadata
Comment @coderabbitai help to get the list of available commands and usage tips.
| /** Sync response schema - use with `sync` handler */ | ||
| successResponseBodySchema: SyncResponse | ||
| responseHeaderSchema?: ResponseHeaders | ||
| /** | ||
| * Alternative response schemas by HTTP status code. | ||
| * Used to define different response shapes for error cases (e.g., 400, 404, 500). | ||
| * | ||
| * @example | ||
| * ```ts | ||
| * responseBodySchemasByStatusCode: { | ||
| * 400: z.object({ error: z.string(), details: z.array(z.string()) }), | ||
| * 404: z.object({ error: z.string() }), | ||
| * } | ||
| * ``` | ||
| */ | ||
| responseBodySchemasByStatusCode?: ResponseSchemasByStatusCode | ||
| serverSentEventSchemas: Events | ||
| isDualMode: true | ||
| metadata?: CommonRouteDefinitionMetadata | ||
| description?: string | ||
| summary?: string | ||
| tags?: readonly string[] |
There was a problem hiding this comment.
I see we are defining pretty much the same type as we have for the rest contract in dual model and SSE. Should we try to reuse the existing one by extending it with SSE/dual-mode extra props?
@kibertoad If you agree, I can try to ask Claude to do it :D
There was a problem hiding this comment.
Nice! if you don't mind, it will be a separate PR :D
Changes
Checklist
major,minor,patchorskip-releaseAI Assistance Tracking
We're running a metric to understand where AI assists our engineering work. Please select exactly one of the options below:
Mark "Yes" if AI helped in any part of this work, for example: generating code, refactoring, debugging support,
explaining something, reviewing an idea, or suggesting an approach.
Summary by CodeRabbit
New Features
Tests