Problem
In packages/durabletask-js-export-history/src/orchestrators/export-job-orchestrator.ts (lines 160–165), when a batch of export activities fails after exhausting all retry attempts, the orchestrator commits a checkpoint with hardcoded zero values:
yield* commitCheckpoint(ctx, jobEntityId, {
scannedInstances: 0, // ← should be scannedCount
exportedInstances: 0, // ← should be batchResult.exportedCount
failures: batchResult.failures,
} as CommitCheckpointRequest);
The actual values are available: scannedCount (line 121) tracks how many instances were listed, and batchResult.exportedCount (returned from processBatchWithRetry at line 220) tracks how many were successfully exported before the batch was marked as failed.
Root Cause
The failure-path checkpoint was written with literal 0 values instead of the computed variables used in the success path (lines 145–148). This appears to be a copy-paste oversight — the success path correctly uses scannedCount and batchResult.exportedCount.
Impact
The ExportJob entity accumulates scannedInstances and exportedInstances via addition in commitCheckpoint() (entity line 142–143). Reporting 0 means:
- Progress statistics undercount real work. If 100 instances are scanned and 80 are exported before 20 fail, the job's counters show 0/0 for that batch instead of 100/80.
- Operators see inaccurate progress data when monitoring long-running export jobs, making it harder to assess how much work was completed before failure.
- The failure-path and success-path behaviors are asymmetric, which is confusing for anyone reading the code.
This affects the @microsoft/durabletask-js-export-history package.
Proposed Fix
Replace the hardcoded zeros with the actual computed values, matching the success-path behavior:
yield* commitCheckpoint(ctx, jobEntityId, {
scannedInstances: scannedCount,
exportedInstances: batchResult.exportedCount,
failures: batchResult.failures,
} as CommitCheckpointRequest);
Problem
In
packages/durabletask-js-export-history/src/orchestrators/export-job-orchestrator.ts(lines 160–165), when a batch of export activities fails after exhausting all retry attempts, the orchestrator commits a checkpoint with hardcoded zero values:The actual values are available:
scannedCount(line 121) tracks how many instances were listed, andbatchResult.exportedCount(returned fromprocessBatchWithRetryat line 220) tracks how many were successfully exported before the batch was marked as failed.Root Cause
The failure-path checkpoint was written with literal
0values instead of the computed variables used in the success path (lines 145–148). This appears to be a copy-paste oversight — the success path correctly usesscannedCountandbatchResult.exportedCount.Impact
The
ExportJobentity accumulatesscannedInstancesandexportedInstancesvia addition incommitCheckpoint()(entity line 142–143). Reporting0means:This affects the
@microsoft/durabletask-js-export-historypackage.Proposed Fix
Replace the hardcoded zeros with the actual computed values, matching the success-path behavior: