What causes "create64 is not supported in Worker shim" in DIYgod/RSSHub?

Use h64ToString on the fully concatenated input instead of create64().update().digest().

DIYgod/RSSHub · error · Error

create64 is not supported in Worker shim

Error message

create64 is not supported in Worker shim

What it means

Thrown by the Workers shim for xxhash-wasm when create64 is called. create64 returns a streaming XXHash<bigint> object (update/digest) that the shim cannot provide without WASM, so it aborts. The shim intentionally supports only the stateless h64ToString fallback used by cache.ts.

Source

Thrown at lib/shims/xxhash-wasm.ts:75

        // In practice, only h64ToString is used and it's called with await xxhash()
        h64: (_input: string, _seed?: bigint): bigint => {
            throw new Error('h64 is not supported in Worker shim, use h64ToString instead');
        },
        h64ToString: (input: string, _seed?: bigint): string => {
            // This needs to be sync to match the API, but we use a simple hash
            // The actual usage in cache.ts awaits xxhash() first, so this works
            let hash = 0n;
            const data = encoder.encode(input);
            for (const byte of data) {
                hash = ((hash << 5n) - hash + BigInt(byte)) & 0xff_ff_ff_ff_ff_ff_ff_ffn;
            }
            return hash.toString(16).padStart(16, '0');
        },
        h64Raw: (_inputBuffer: Uint8Array, _seed?: bigint): bigint => {
            throw new Error('h64Raw is not supported in Worker shim');
        },
        create64: (_seed?: bigint): XXHash<bigint> => {
            throw new Error('create64 is not supported in Worker shim');
        },
    };
}

export default xxhash;

View on GitHub (pinned to bed535e087)

Solutions

Use h64ToString on the fully concatenated input instead of create64().update().digest().
Move the streaming-hash logic out of the Worker bundle into the Node-only entry.
If only a 32-bit stream is needed, use create32 which IS implemented in the shim (lib/shims/xxhash-wasm.ts:37).

Example fix

// before
const h = (await xxhash()).create64(seed);
for (const c of chunks) h.update(c);
const digest = h.digest();
// after
const h = (await xxhash()).create32(seed);
for (const c of chunks) h.update(c);
const digest = h.digest();

Defensive patterns

Strategy: type-guard

Validate before calling

function canStream64(api: any): boolean {
  try { const h = api.create64(); return typeof h?.update === 'function'; } catch { return false; }
}

Type guard

const isCreate64Usable = (api: XXHashAPI): boolean => {
  try { api.create64(); return true; } catch { return false; }
};

Try / catch

try {
  const h = (await xxhash()).create64(seed);
  chunks.forEach((c) => h.update(c));
  return h.digest();
} catch (e) {
  if (/not supported in Worker shim/.test((e as Error).message)) {
    return (await xxhash()).h64ToString(chunks.join(''), seed);
  }
  throw e;
}

Prevention

Avoid the streaming 64-bit API in code that runs in the Worker bundle - prefer stateless h64ToString.
For incremental hashing under Workers, use create32 which the shim supports.
Document the Worker-incompatible methods at the top of any module that uses xxhash.

When it happens

Trigger: Calling xxhash().create64(seed) and then .update()/.digest() in code that ends up in the Worker bundle. Any new code that streams chunks through a 64-bit hasher will hit this in the Worker environment.

Common situations: Introducing a code path that incrementally hashes large payloads with create64; pulling in a shared utility that picks create64 over h64ToString; cache key generation that was refactored to use the streaming API.

Related errors

AI-assisted analysis of DIYgod/RSSHub@bed535e087 (2026-08-12). Data as JSON: /api/errors/5a652da21de516b1. Report an issue: GitHub.