Workers SDK Issue Reports

← Back to Dashboard

#7636 D1 execute --remote throws forEach undefined error

Recommendation:KEEP OPEN
Difficulty:easy
Reasoning:

Valid bug: pollUntilComplete in execute.ts assumes response.messages is always defined but API can return undefined. One-line fix needed to add null-safety check.

Suggested Action:

Add null-safety: (response.messages ?? []).forEach(...)

Analysis Report

Issue Review: cloudflare/workers-sdk#7636

Summary

D1 execute command with --remote --file throws "Cannot read properties of undefined (reading 'forEach')" when API response lacks messages array.

Findings

  • Created: 2024-12-27
  • Updated: 2025-10-30
  • Version: wrangler 3.60.3 (reported) -> 4.60.0 (current)
  • Component: D1 (wrangler)
  • Labels: bug, d1
  • Comments: 1 (team member acknowledged, investigating)

Key Evidence

  1. Bug Location Identified: The error occurs in packages/wrangler/src/d1/execute.ts in the pollUntilComplete function:

    response.messages.forEach((line) => {
      logger.log(`🌀 ${line}`);
    });
    

    When the API returns a response where messages is undefined, this line throws the TypeError.

  2. Type Definition Mismatch: The ImportPollingResponse type in types.ts defines messages: string[] as required, but the actual API response can sometimes omit it.

  3. No Fix Found:

    • No PRs explicitly reference issue #7636
    • No changelog entries mention this specific forEach error
    • PR #11467 and #11880 reduced Sentry noise for D1 errors but didn't fix the underlying bug
    • The code still lacks null-safety checks for response.messages
  4. Related Issues:

    • Issue #11087 reports similar D1 execute remote failures with large files ("TypeError: fetch failed")
    • Both issues affect --remote --file execution path
  5. Version Gap:

    • Reported against wrangler 3.60.3
    • Current version is 4.60.0 (major version upgrade)
    • Bug was reported over a year ago with maintainer acknowledgment but no fix

Recommendation

Status: KEEP OPEN

Reasoning: This is a valid bug that still exists in the current codebase. The error handling in pollUntilComplete is incomplete - it assumes response.messages is always defined when the TypeScript type says it should be, but the actual API can return undefined. The fix is straightforward: add null-safety check like (response.messages ?? []).forEach(...) or optional chaining response.messages?.forEach(...).

Action: Keep open for fix. The fix is a one-line change in packages/wrangler/src/d1/execute.ts to handle undefined messages:

// Current (buggy):
response.messages.forEach((line) => {
  logger.log(`🌀 ${line}`);
});

// Fixed:
(response.messages ?? []).forEach((line) => {
  logger.log(`🌀 ${line}`);
});

Also consider updating the ImportPollingResponse type to make messages optional (messages?: string[]) to match actual API behavior.

Suggested Comment

Thank you for reporting this issue. We've identified the root cause - the pollUntilComplete function in the D1 execute code doesn't handle cases where the API response's messages array is undefined.

This appears to still be present in the codebase. Could you try upgrading to the latest wrangler version (4.60.0) to confirm if this is still occurring? If so, we can prioritize a fix to add proper null-safety handling for the response messages.

In the meantime, as a workaround, you could try:

  1. Breaking your SQL file into smaller chunks
  2. Using wrangler d1 execute --remote --command "..." for individual statements

Notes & Feedback (0)

No notes yet.

Add Note