refactor: modularize 3.7K-line imageGeneration.ts (Issue #3594)

[oyi77]

Summary

This PR addresses another core backend massive file from Issue #3594: open-sse/handlers/imageGeneration.ts at 3,776 lines.

Changes

Splits the monolithic image generation handler into 13 domain-focused files inside open-sse/handlers/imageGeneration/:

File	Contents
utils.ts	URL normalizers, prompt extraction, aspect ratio parsing, error sanitization
logging.ts	Success/error logging into usageDb
core.ts	The main handleImageGeneration switch dispatcher
openai.ts	OpenAI and OpenAI-compatible image-to-image/edit models
stability.ts	Stability AI integration
blackForestLabs.ts	Black Forest Labs integration and polling
fal.ts, gemini.ts, imagen3.ts	Fal.ai, Gemini, and Imagen 3 handlers
chatgptWeb.ts, codex.ts, kie.ts	Specialized web and executor handlers
specialty.ts	Recraft, Hyperbolic, NanoBanana, ComfyUI, SDWebUI, Haiper, Leonardo, Ideogram
index.ts	Re-exports everything cleanly

Results

• imageGeneration.ts: 3,776 lines → 1 line (re-exports imageGeneration/index.ts)
• All imports between files are resolved correctly.
• Full backward compatibility: all exports are preserved through the facade.

Verification

• npm run typecheck:core — passes cleanly.
• npx eslint open-sse/handlers/imageGeneration/*.ts — 0 errors (preserves pre-existing any-warnings).
• Strictly structural refactoring with identical runtime behavior.

Resolves part of #3594.

[gemini-code-assist]

Code Review

This pull request implements a major refactoring and modularization of the chatCore and imageGeneration handlers, soft-deprecates the @omniroute/opencode-provider package, migrates public OAuth client IDs to secure credential resolution, and resolves several routing, API, and documentation issues. The code review identified critical runtime ReferenceError bugs in the newly added frontend files (connectionManagement.tsx and utils.tsx) due to missing imports of constants and utility functions (such as ERROR_TYPE_LABELS, formatTimeAgo, and CODEX_REASONING_STRENGTH_OPTIONS). Additionally, several high-severity defensive programming issues were highlighted in the modularized image generation handlers where API JSON responses are accessed directly without null or object checks, posing a risk of runtime TypeErrors.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Critical Bug: CODEX_ACCOUNT_SERVICE_TIER_VALUES is used here but is not defined or imported in this file. This will cause a runtime ReferenceError when rendering the component. Please import it from the appropriate constants module.

[gemini-code-assist]

Critical Bug: ERROR_TYPE_LABELS is used here but is not defined or imported in this file. This will cause a runtime ReferenceError when rendering the component. Please import it from the appropriate constants module.

[gemini-code-assist]

Critical Bug: CC_COMPATIBLE_DEFAULT_CHAT_PATH is used here but is not defined or imported anywhere in this file. This will cause a runtime ReferenceError when opening the modal or validating a compatible node. Please import it from the appropriate constants module.

[gemini-code-assist]

Critical Bug: CODEX_REASONING_STRENGTH_OPTIONS is used here but is not defined or imported in this file. This will cause a runtime ReferenceError when rendering the component. Please import it from the appropriate constants module.

[gemini-code-assist]

Critical Bug: formatTimeAgo is used here but is not defined or imported in this file. This will cause a runtime ReferenceError when rendering the component. Please import it from the appropriate utility module.

[gemini-code-assist]

Defensive programming: status returned from statusRes.json() can be null or not an object if the API response is empty or malformed. Accessing status.status directly without a null/object check can cause a runtime TypeError.

      if (status && typeof status === "object") {
        if (status.status === "completed" || status.status === "succeeded") {
          const imgUrl = status.creation_url || status.output?.image_url;
          if (imgUrl) {
            const imgRes = await fetch(imgUrl);
            if (!imgRes.ok) {
              return {
                success: false,
                status: imgRes.status,
                error: `Failed to download image: ${imgRes.status}`,
              };
            }
            const buf = await imgRes.arrayBuffer();
            saveCallLog({
              method: "POST",
              path: "/v1/images/generations",
              status: 200,
              model: `${provider}/${model}`,
              provider,
              duration: Date.now() - startTime,
            }).catch(() => {});
            return {
              success: true,
              data: {
                created: Math.floor(Date.now() / 1000),
                data: [{ b64_json: Buffer.from(buf).toString("base64") }],
              },
            };
          }
        }
        if (status.status === "failed") {
          saveCallLog({
            method: "POST",
            path: "/v1/images/generations",
            status: 502,
            model: `${provider}/${model}`,
            provider,
            duration: Date.now() - startTime,
            error: "Haiper image generation failed",
          }).catch(() => {});
          return { success: false, status: 502, error: "Haiper image generation failed" };
        }
      }

[gemini-code-assist]

Defensive programming: status returned from statusRes.json() can be null or not an object, which would make gen null and cause a runtime TypeError when accessing gen.status. Please add a null/object check.

      const gen = status && typeof status === "object" ? (status.generations_by_pk || status) : null;
      if (gen && typeof gen === "object") {
        if (gen.status === "COMPLETE") {
          const imgUrl = gen.generated_images?.[0]?.url;
          if (imgUrl) {
            const imgRes = await fetch(imgUrl);
            if (!imgRes.ok) {
              return {
                success: false,
                status: imgRes.status,
                error: `Failed to download image: ${imgRes.status}`,
              };
            }
            const buf = await imgRes.arrayBuffer();
            saveCallLog({
              method: "POST",
              path: "/v1/images/generations",
              status: 200,
              model: `${provider}/${model}`,
              provider,
              duration: Date.now() - startTime,
            }).catch(() => {});
            return {
              success: true,
              data: {
                created: Math.floor(Date.now() / 1000),
                data: [{ b64_json: Buffer.from(buf).toString("base64") }],
              },
            };
          }
        }
        if (gen.status === "FAILED") {
          saveCallLog({
            method: "POST",
            path: "/v1/images/generations",
            status: 502,
            model: `${provider}/${model}`,
            provider,
            duration: Date.now() - startTime,
            error: "Leonardo image generation failed",
          }).catch(() => {});
          return { success: false, status: 502, error: "Leonardo image generation failed" };
        }
      }

[gemini-code-assist]

Defensive programming: data returned from res.json() can be null or not an object. Accessing data.data directly without a null/object check can cause a runtime TypeError.

Suggested change

	const data = await res.json();
	if (data.data && data.data.length > 0) {
	const data = await res.json();
	if (data && typeof data === "object" && Array.isArray(data.data) && data.data.length > 0) {

[gemini-code-assist]

Defensive programming: data returned from response.json() can be null or not an object. Accessing data.images, data.data, data.url, etc. directly without a null/object check can cause a runtime TypeError.

    if (data && typeof data === "object") {
      if (Array.isArray(data.images)) {
        images.push(
          ...data.images.map((img: Record<string, unknown>) => ({
            b64_json: img.image ?? img.b64_json ?? img.url ?? img,
            revised_prompt: body.prompt,
          }))
        );
      } else if (Array.isArray(data.data)) {
        images.push(...data.data);
      } else if (data.url || data.b64_json || data.image) {
        images.push({
          b64_json: data.image || data.b64_json || data.url,
          url: data.url,
          revised_prompt: body.prompt,
        });
      }
    }

[gemini-code-assist]

Defensive programming: initialPayload returned from response.json() can be null or not an object. Accessing initialPayload.polling_url directly without a null/object check can cause a runtime TypeError.

Suggested change

	const initialPayload = await response.json();
	const finalPayload = initialPayload.polling_url
	? await pollBlackForestLabsResult({
	pollingUrl: initialPayload.polling_url,
	token,
	body,
	log,
	})
	: initialPayload;
	const initialPayload = await response.json();
	const finalPayload = (initialPayload && typeof initialPayload === "object" && initialPayload.polling_url)
	? await pollBlackForestLabsResult({
	pollingUrl: initialPayload.polling_url,
	token,
	body,
	log,
	})
	: initialPayload;

[diegosouzapw]

Thanks @oyi77 for the modularization work on imageGeneration.ts (Issue #3594). I can't merge this as it currently stands — and the reason is structural, not about the quality of the split:

1. It's a stacked/cumulative chain. This branch carries ~49–55 commits all starting from chore(release): open v3.8.23 development cycle, and the per-PR additions grow monotonically (refactor: modularize providerRegistry.ts (Issue #3594) #3617 ≈ +22k → refactor: modularize 3.1K-line providers.ts constants (Issue #3594) #3646 ≈ +52k). Each refactor branch is built on top of the previous one, so merging any single PR drags in all the earlier refactors too. That makes each PR impossible to review in isolation and guarantees conflicts between them.

2. The base is stale (v3.8.23 era). Since these were cut, release/v3.8.24 has merged dozens of PRs — including changes to the very files several of these PRs modularize (e.g. providerRegistry.ts grew via fix(providers): correct Ollama Cloud kimi-k2.7-code capabilities (#3761) #3768, validation.ts via fix(providers): repair qwen-web validation + stop mislabeling benign redirects as SSRF (#3288, #3758) #3767, plus combo/stream/usage edits). GitHub now reports this PR as CONFLICTING, and the conflicts are substantial.

What would let this land: re-cut it as a single, independent PR branched from the current release/v3.8.24 tip, modularizing only imageGeneration.ts (not stacked on the other refactors), small enough to review on its own. One file per PR, rebased on current release. I'll gladly review and merge them in that form — the god-file modularization goal is worth it; it's the 14-deep stack on a 2-week-old base that can't go in. Leaving this open so nothing is lost.

[oyi77]

Closed in favor of clean re-cut — see #3793 (providerRegistry), #3798 (combo), #3797 (validation), #3796 (imageGeneration), #3795 (usage), #3794 (providers). Only modularization commits were cherry-picked onto current release/v3.8.24 — no stacked dependencies, no unrelated changes.