ruvnet/ruflo · error · Error

Invalid completion type

Error message

Invalid completion type

What it means

Thrown in the final else branch of endpointOai when the parsed completion value is neither 'completions' nor 'chat_completions'. In practice this is effectively unreachable: endpointOAIParametersSchema.parse() validates completion against z.union([literal('completions'), literal('chat_completions')]) with a default of 'chat_completions', so any value reaching the branch must have bypassed Zod (e.g. calling the internal function with hand-parsed input, or a schema regression that widened the union).

Source

Thrown at ruflo/src/ruvocal/src/lib/server/endpoints/openai/endpointOai.ts:264

					{
						body: { ...body, ...extraBody },
						headers: {
							"ChatUI-Conversation-ID": conversationId?.toString() ?? "",
							"X-use-cache": "false",
							...(locals?.token ? { Authorization: `Bearer ${locals.token}` } : {}),
							// Bill to organization if configured
							...(locals?.billingOrganization
								? { "X-HF-Bill-To": locals.billingOrganization }
								: {}),
						},
						signal: abortSignal,
					}
				);
				return openAIChatToTextGenerationSingle(openChatAICompletion, () => routerMetadata);
			}
		};
	} else {
		throw new Error("Invalid completion type");
	}
}

View on GitHub (pinned to 6b01dc5a68)

Solutions

  1. Always feed input through endpointOAIParametersSchema.parse(input) so completion is validated/defaulted to a known literal.
  2. If you add a new completion mode, add its branch (e.g. else if (completion === 'responses')) before the final else.
  3. Search for direct callers of endpointOai that skip the schema and route them through it.
  4. Turn the final else into an exhaustiveness check on a string-enum union so a new literal is a compile error.

Example fix

// before
} else {
  throw new Error("Invalid completion type");
}

// after — exhaustiveness via never
type Completion = "completions" | "chat_completions";
function assertNever(x: never): never { throw new Error(`Invalid completion type: ${x}`); }
} else {
  assertNever(completion as never);
}
Defensive patterns

Strategy: type-guard

Validate before calling

const COMPLETIONS = ['completions', 'chat_completions'] as const;
type Completion = typeof COMPLETIONS[number];
function parseCompletion(v: unknown): Completion {
  if (typeof v === 'string' && (COMPLETIONS as readonly string[]).includes(v)) return v as Completion;
  return 'chat_completions'; // safe default
}

Type guard

function isValidCompletion(v: unknown): v is 'completions' | 'chat_completions' { return v === 'completions' || v === 'chat_completions'; }

Prevention

When it happens

Trigger: Calling endpointOai with a completion value other than the two literals after skipping endpointOAIParametersSchema.parse — e.g. an internal caller destructures input directly, or a future schema change adds a literal without adding a matching branch. Through normal Zod-validated entry the throw cannot fire.

Common situations: A refactor added a third completion mode to the schema union but forgot to add its branch in the function; a caller bypasses .parse() and passes a raw object; a default was removed so undefined reaches the branch (only possible if the schema's default is also removed).

Related errors


AI-assisted analysis of ruvnet/ruflo@6b01dc5a68 (2026-08-12). Data as JSON: /api/errors/19dccd9e9a8e50db. Report an issue: GitHub.