feat:Refactor LemurTaskParams schema to remove inheritance and update fields #111
Conversation
WalkthroughThe schema for Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
✨ Finishing Touches🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
coderabbitai
bot
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
src/libs/AssemblyAI/openapi.yaml (1)
5636-5642: Unnecessary single-itemallOfwrapper adds avoidable complexity
LemurTaskParamsnow wraps its single object schema inside anallOf:list that contains only that same object.
This extra indirection has no functional benefit but complicates downstream tooling (codegen, validation, diffing).-allOf: - - type: object +type: object +additionalProperties: false +properties: + ...Unless you intend to add additional
allOfmembers, flatten the structure.
Cleaner YAML ≙ fewer surprises for generators like OpenAPI-Generator & Fern.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
src/libs/AssemblyAI/Generated/AssemblyAI.JsonConverters.LemurTaskParams.g.csis excluded by!**/generated/**src/libs/AssemblyAI/Generated/AssemblyAI.Models.LemurTaskParams.g.csis excluded by!**/generated/**src/libs/AssemblyAI/Generated/AssemblyAI.Models.LemurTaskParamsVariant1.g.csis excluded by!**/generated/**
📒 Files selected for processing (1)
src/libs/AssemblyAI/openapi.yaml(1 hunks)
| transcript_ids: | ||
| x-label: Transcript IDs | ||
| description: | | ||
| A list of completed transcripts with text. Up to a maximum of 100 hours of audio. | ||
| Use either transcript_ids or input_text as input into LeMUR. | ||
| type: array | ||
| items: | ||
| x-label: Transcript ID | ||
| type: string | ||
| format: uuid |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Schema now duplicates fields from LemurBaseParams – consider composition to stay DRY
transcript_ids, input_text, max_output_size, temperature, etc. are copied wholesale.
Keeping two independent copies means the moment you tweak validation in one place, the other silently drifts.
A safer pattern:
LemurTaskParams:
allOf:
- $ref: "#/components/schemas/LemurBaseParams"
- type: object
required: [prompt]
properties:
prompt:
type: stringThis keeps the single source-of-truth in LemurBaseParams and just adds the prompt requirement.
Also applies to: 5671-5685
🤖 Prompt for AI Agents
In src/libs/AssemblyAI/openapi.yaml around lines 5647 to 5656, the schema
duplicates fields from LemurBaseParams, causing maintenance issues. Refactor
LemurTaskParams to use composition by referencing LemurBaseParams with allOf,
then add or override properties like prompt as needed. This keeps validation
centralized and avoids duplication. Apply the same pattern to lines 5671 to
5685.
| x-label: Input text | ||
| description: | | ||
| Custom formatted transcript data. Maximum size is the context limit of the selected model. | ||
| Use either transcript_ids or input_text as input into LeMUR. | ||
| type: string | ||
| final_model: | ||
| x-label: Final model | ||
| description: | | ||
| The model that is used for the final prompt after compression is performed. | ||
| default: "default" | ||
| oneOf: | ||
| - $ref: "#/components/schemas/LemurModel" | ||
| max_output_size: |
There was a problem hiding this comment.
final_model definition diverges from the canonical one – risk of breaking SDKs
Previously, final_model in LemurBaseParams used anyOf + x-ts-type + x-go-type to allow either an enum value or an arbitrary string.
The duplication here:
final_model:
... # description kept
default: "default"
oneOf: # <-- switched to oneOf
- $ref: "#/components/schemas/LemurModel"- Switching from
anyOf→oneOftightens validation and may reject inputs that were valid before (e.g. a custom model string). x-ts-type/x-go-typehints are lost, so generated SDKs will expose different types for the same field across request objects.
Recommend re-using the original definition via $ref (or copy it verbatim) to keep behaviour and typings consistent:
- oneOf:
- - $ref: "#/components/schemas/LemurModel"
+ anyOf:
+ - $ref: "#/components/schemas/LemurModel"
+ - type: string
+ x-ts-type: LiteralUnion<LemurModel, string>
+ x-go-type: LeMURModelFailing to align these will cause breaking changes for clients generated from this spec.
🤖 Prompt for AI Agents
In src/libs/AssemblyAI/openapi.yaml around lines 5658 to 5670, the final_model
field definition changed from using anyOf with x-ts-type and x-go-type to oneOf
without these type hints, which restricts valid inputs and breaks SDK typings.
To fix this, revert final_model to use the original anyOf structure including
x-ts-type and x-go-type annotations, either by referencing the original schema
or copying it verbatim, ensuring consistent validation and SDK compatibility.
Summary by CodeRabbit
New Features
Bug Fixes
Documentation