Skip to content

Refactor data parameter in TranscriptionWorkerClient.ts to use explicit types instead of any #220

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ysdede wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Refactor data parameter in TranscriptionWorkerClient.ts to use explicit types instead of any #220

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 11 additions & 1 deletion src/lib/transcription/TranscriptionWorkerClient.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -99,6 +99,16 @@ export interface WorkerMessageMap {
V4_FINALIZE_TIMEOUT: { payload: void; response: V4ProcessResult | null };
V4_RESET: { payload: void; response: void };
}

/** Valid incoming messages from the worker */
export type WorkerIncomingMessage =
| { type: 'MODEL_PROGRESS'; payload: ModelProgress; id?: number }
| { type: 'MODEL_STATE'; payload: ModelState; id?: number }
| { type: 'V3_CONFIRMED'; payload: { text: string; words: any[] }; id?: number }
| { type: 'V3_PENDING'; payload: { text: string; words: any[] }; id?: number }
Comment on lines +107 to +108
Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot Mar 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Using any[] for the words property is a missed opportunity to improve type safety, which is the main goal of this pull request. Consider using a more specific type for the elements in the words array. The existing TranscriptionWord type (which would need to be added to the imports from ./types) seems like a good candidate. If its structure doesn't match, a new interface should be defined for these V3 tokens.

Suggested change
| { type: 'V3_CONFIRMED'; payload: { text: string; words: any[] }; id?: number }
| { type: 'V3_PENDING'; payload: { text: string; words: any[] }; id?: number }
| { type: 'V3_CONFIRMED'; payload: { text: string; words: TranscriptionWord[] }; id?: number }
| { type: 'V3_PENDING'; payload: { text: string; words: TranscriptionWord[] }; id?: number }

| { type: 'ERROR'; payload: string; id?: number }
| { type: string; payload?: any; id: number };
Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot Mar 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

This generic catch-all with payload?: any significantly weakens the discriminated union and undermines the goal of this refactoring. You can create a more specific type for the payload of response messages by creating a union of all possible response types from WorkerMessageMap. This would significantly improve type safety and make the contract with the worker much safer.

Suggested change
| { type: string; payload?: any; id: number };
| { type: string; payload?: void | TranscriptionResult | { text: string } | TokenStreamResult | V4ProcessResult | null; id: number };

Comment on lines +104 to +110
Copy link
Copy Markdown

@qodo-code-review qodo-code-review Bot Mar 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Missing transcription_result variant 🐞 Bug ✓ Correctness

WorkerIncomingMessage cannot represent { type: 'TRANSCRIPTION_RESULT', payload: ... } messages
emitted by transcription.worker.ts because the union’s fallback branch requires id: number, but
that worker message has no id.
Agent Prompt 
### Issue description
`WorkerIncomingMessage` is exported as the set of valid incoming worker messages, but it currently cannot represent the `{ type: 'TRANSCRIPTION_RESULT', payload: ... }` message that the worker emits without an `id`. This makes the type contract incorrect and undermines the goal of having a single source of truth.

### Issue Context
The worker emits fire-and-forget callback messages (no `id`) and request/response messages (with `id`). The union’s catch-all requires `id: number`, so any additional fire-and-forget message types must be explicitly modeled.

### Fix Focus Areas
- src/lib/transcription/TranscriptionWorkerClient.ts[103-111]
- src/lib/transcription/transcription.worker.ts[37-45]

### What to change
- Add an explicit union member for `TRANSCRIPTION_RESULT` matching the worker’s shape (no `id`).
  - Example:
    - `| { type: 'TRANSCRIPTION_RESULT'; payload: /* correct payload type */; id?: number }`
- (Optional but recommended) Consider tightening the fallback branch so it doesn’t unintentionally constrain future non-id messages (e.g., split fallback into `id?: number` or remove it in favor of explicit variants).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


export class TranscriptionWorkerClient {
private static readonly DISPOSED_ERROR_MESSAGE = 'TranscriptionWorkerClient disposed';
private worker: Worker;
Expand Down Expand Up @@ -126,7 +136,7 @@ export class TranscriptionWorkerClient {
};
}

private handleMessage(data: any) {
private handleMessage(data: WorkerIncomingMessage) {
const { type, payload, id } = data;

// Handle promise resolutions
Expand Down
Loading