Skip to content

fix: preserve export progress statistics on batch failure#313

Closed
YunchuWang wants to merge 1 commit into
microsoft:mainfrom
YunchuWang:copilot-finds/bug/fix-batch-failure-progress-stats
Closed

fix: preserve export progress statistics on batch failure#313
YunchuWang wants to merge 1 commit into
microsoft:mainfrom
YunchuWang:copilot-finds/bug/fix-batch-failure-progress-stats

Conversation

@YunchuWang

Copy link
Copy Markdown
Member

Summary

  • Commit the actual scanned and exported counts when an export batch fails.
  • Preserve the reported failure details instead of resetting progress to zero.
  • Add orchestrator regression coverage for partial batch failures.

Fixes #213

Testing

  • npm test -w @microsoft/durabletask-js-export-history -- --runTestsByPath test/export-job-orchestrator.spec.ts
  • npm run build -w @microsoft/durabletask-js-export-history

… batch failure

When a batch of export activities fails after exhausting all retry attempts,
the orchestrator commits a checkpoint with scannedInstances=0 and
exportedInstances=0. This discards the actual work done: the number of
instances that were scanned and the number that were successfully exported
before the batch was marked as failed.

The entity accumulates these counters via addition, so reporting 0 means
the job's progress statistics undercount the real work, giving operators
inaccurate progress data.

Fix: Use the actual scannedCount and batchResult.exportedCount values in
the failure-path checkpoint, matching the success-path behavior.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot AI review requested due to automatic review settings July 17, 2026 16:40

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes progress reporting in the export-history job orchestrator so that, when an export batch ultimately fails (after exhausting the batch-level retry loop), the job’s checkpoint still records the actual scanned/exported counts and preserves failure details. This aligns failure-path checkpointing behavior with the success path and addresses the incorrect “0/0 progress” reporting described in issue #213.

Changes:

  • Update failure-path checkpoint commits to use scannedCount and batchResult.exportedCount instead of hardcoded zeros.
  • Add regression tests that validate checkpoint counts for partial-batch failures, full-batch failures, and successful batches.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
packages/durabletask-js-export-history/src/orchestrators/export-job-orchestrator.ts Fixes failure-path checkpointing to persist actual scanned/exported counts alongside failure details.
packages/durabletask-js-export-history/test/export-job-orchestrator.spec.ts Adds regression coverage to ensure progress statistics are preserved on batch failure and correct on success.

@YunchuWang

Copy link
Copy Markdown
Member Author

Closing after a first-principles cross-SDK review.

The issue's premise ("copy-paste oversight") is not supported. The .NET sibling ExportJobOrchestrator deliberately uses the same scannedInstances: 0, exportedInstances: 0, checkpoint: null on the terminal-failure path, with an explicit comment: "Batch failed after all retries - commit without checkpoint (don't move cursor), record failures." export-history exists only in JS + .NET, so .NET is the sole cross-SDK reference and it treats 0/0 as intentional.

Why 0/0 is defensive, not accidental: checkpoint counts accumulate by addition, and on failure the cursor is intentionally not advanced (commit-checkpoint-request.ts documents this as "allowing retry of the same batch"). Crediting real counts on a failed attempt would double-count if that page is ever reprocessed.

Net: in the current code failure is terminal (throws → markAsFailed; no resume op; create resets counters), so this change is harmless today and does make the final report more accurate. But it (a) diverges from .NET's deliberate behavior, breaking the repo's cross-SDK consistency convention, and (b) reintroduces a latent double-count risk if a resume-from-failed feature is ever added. This needs a cross-SDK semantics decision by maintainers rather than a one-sided JS change, so closing as not planned.

@YunchuWang YunchuWang closed this Jul 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[copilot-finds] Bug: Export job orchestrator reports zero progress statistics on batch failure

3 participants