jackwener/OpenCLI · error · CommandExecutionError

Midjourney media transfer lost its browser buffer at byte ${

Error message

Midjourney media transfer lost its browser buffer at byte ${offset}

What it means

While reading the media back out of the browser window buffer in bounded base64 chunks, a chunk read returned nothing (empty/non-string). This means the browser-side buffer stored under transferKey disappeared or was never populated at that offset, so the transfer is aborted to prevent a corrupted file.

Source

Thrown at clis/midjourney/utils.js:584

    // Returning a complete base64 file in one Browser Bridge response can
    // exceed the daemon message limit. Pull it out in bounded chunks instead.
    const parts = [];
    const chunkSize = 96 * 1024;
    for (let offset = 0; offset < size; offset += chunkSize) {
      const base64 = unwrapEvaluateResult(await page.evaluate((key, start, length) => {
        const bytes = window[key];
        if (!(bytes instanceof Uint8Array)) return null;
        const chunk = bytes.subarray(start, Math.min(bytes.length, start + length));
        let binary = '';
        const binaryChunkSize = 0x8000;
        for (let index = 0; index < chunk.length; index += binaryChunkSize) {
          binary += String.fromCharCode(...chunk.subarray(index, index + binaryChunkSize));
        }
        return btoa(binary);
      }, transferKey, offset, chunkSize));
      if (typeof base64 !== 'string' || !base64) {
        throw new CommandExecutionError(`Midjourney media transfer lost its browser buffer at byte ${offset}`);
      }
      parts.push(Buffer.from(base64, 'base64'));
    }
    const buffer = Buffer.concat(parts);
    if (buffer.length !== size) {
      throw new CommandExecutionError(`Midjourney media transfer size mismatch: expected ${size}, received ${buffer.length}`);
    }
    return { buffer, mime: String(payload.type || '').split(';', 1)[0].toLowerCase() };
  } finally {
    await page.evaluate((key) => {
      delete window[key];
      return true;
    }, transferKey).catch(() => {});
  }
}

function sniffMediaMime(buffer) {
  if (!Buffer.isBuffer(buffer) || buffer.length < 4) return null;

View on GitHub (pinned to 49907e53dc)

Solutions

Retry the download ensuring the page is not navigated during the transfer.
Download media one at a time (no concurrent transfers sharing the same page/key).
Use a dedicated/stable page for the transfer.
Reduce pressure on the browser session and retry if instability persists.

Defensive patterns

Strategy: try-catch

Validate before calling

if (page.isClosed()) throw new Error('Page unstable; stabilize before chunked transfer');

Try / catch

try {
  await downloadMedia(page, url);
} catch (err) {
  if (/lost its browser buffer/.test(err.message)) {
    page = await newPage(browser); // fresh page restores window buffer
    await downloadMedia(page, url);
  } else throw err;
}

Prevention

Never navigate or reload the page mid-transfer.
Use a dedicated page per download; never share one page for concurrent transfers.
Keep transfers within a stable browser session (avoid long-lived fragile pages).
Keep automation scripts from deleting window keys during a transfer.

When it happens

Trigger: The page was reloaded or navigated between chunk reads, wiping window[transferKey]; another script overwrote or deleted the buffer; the page.evaluate call returned an empty string for a chunk; concurrent transfers on the same page clobbering the key.

Common situations: Automation that navigates the page while a large video download is still chunking; sharing one browser page across parallel downloads; very long transfers hitting page instability.

Related errors

AI-assisted analysis of jackwener/OpenCLI@49907e53dc (2026-08-29). Data as JSON: /api/errors/40a1f354cb13a589. Report an issue: GitHub.