Issue Review: cloudflare/workers-sdk#6401

Summary

User reports that wrangler d1 execute --file returns astronomically inflated rows_read metrics (70M+ rows read for a 12K row database) after executing a DELETE statement with ~1K values in an IN clause.

Findings

• Created: 2024-08-02
• Updated: 2025-10-30
• Version: wrangler 3.67.1 -> 4.60.0 (current)
• Component: D1 (wrangler d1 execute --file)
• Labels: bug, d1
• Comments: 0

Key Evidence

1. No fix found: No PR references fixing #6401, changelog has no mention of this issue
2. Root cause is D1 backend: Code analysis shows wrangler simply displays metrics returned by D1 API:
   • packages/wrangler/src/d1/execute.ts:316-320 logs metrics directly from ImportPollingResponse.result.meta
   • The rows_read value comes from D1's /import API endpoint, not calculated by wrangler
3. Metrics structure: ImportPollingResponse.result.meta.rows_read is returned as-is from D1 backend
4. Issue is 18+ months old with no comments or activity from maintainers

Root Cause Analysis

The issue is NOT in wrangler - it's in the D1 backend service. The code path is:

1. User runs wrangler d1 execute --file <sql-file> --remote
2. Wrangler uploads the SQL file via uploadAndBeginIngestion() at execute.ts:275
3. D1 backend processes the file and returns metrics via /import API
4. Wrangler displays returned metrics at execute.ts:316-320:

   logger.log(
     `Executed ${num_queries} queries in ${meta.duration.toFixed(2)}ms ` +
     `(${meta.rows_read} rows read, ${meta.rows_written} rows written)`
   );
   

The rows_read metric is inflated by D1's backend, likely due to:

• How D1 counts rows scanned during DELETE ... WHERE tid IN (...) operations
• Possible counting of index scans or internal page reads
• The dashboard showing the same inflated number confirms this is backend-originated

Wrangler Code References

• packages/wrangler/src/d1/execute.ts:316-320 - Metrics display
• packages/wrangler/src/d1/types.ts:85-98 - ImportPollingResponse type definition showing meta.rows_read

Recommendation

Status: KEEP OPEN (but needs re-labeling)

Reasoning: This is a valid bug report, but the issue is with the D1 backend service, not wrangler. The wrangler CLI correctly displays whatever metrics the D1 API returns. The inflated rows_read count appears to be how D1 calculates/reports rows scanned during bulk DELETE operations.

Action:

1. Add a comment clarifying this is a D1 backend issue, not a wrangler CLI issue
2. Consider transferring/linking to D1 product team's tracking system
3. Request more details about the billing implications (are users being charged for inflated row reads?)

Suggested Comment

Thank you for the detailed bug report. After investigation, the rows_read metric displayed by wrangler comes directly from the D1 backend API - wrangler simply displays what D1 returns (see packages/wrangler/src/d1/execute.ts:316-320).

The fact that you see the same inflated number in the web dashboard confirms this is a D1 backend issue rather than a wrangler display issue.

I'm keeping this issue open but wanted to clarify that fixing this would require changes to how D1's backend calculates/reports row metrics for DELETE ... WHERE IN (...) operations, particularly when processing imported SQL files.

Could you clarify if this inflated rows_read count is affecting your D1 billing? That would help prioritize this issue.

/cc @cloudflare/d1-team (or appropriate D1 backend team label)

Proposed Solution

Since this is a D1 backend issue, no wrangler code changes are needed. However, if wrangler wanted to add a workaround or clarification:

Option A: Add a disclaimer to file imports (Easy)

Add a note in the output warning users that rows_read for bulk operations may include index scans:

// In execute.ts around line 316
logger.log(
  `Executed ${num_queries} queries in ${meta.duration.toFixed(2)}ms ` +
  `(${meta.rows_read} rows read, ${meta.rows_written} rows written)`
);
logger.log(
  chalk.dim('Note: rows_read includes index scans and may appear higher than expected for bulk operations.')
);

Option B: No wrangler changes - escalate to D1 backend team

This is the recommended approach as the root cause is in D1's metric calculation.

Implementation Difficulty: N/A for wrangler (backend issue)

Files that would need modification (if Option A):

• packages/wrangler/src/d1/execute.ts

Testing recommendations:

• This requires D1 backend testing, not wrangler testing
• Reproduction would involve running a DELETE with IN clause containing many values against a remote D1 database