Add per-attempt retry metadata tags in OrchestrationContext.ScheduleWithRetry

[Varshitha Bachu (bachuv)]

Summary

OrchestrationContext.ScheduleWithRetry<T> now stamps two reserved tags on
every per-attempt schedule:

Tag	Value
dt.retry.attempt	attempt counter (starts at 1), decimal, InvariantCulture
dt.retry.maxAttempts	retryOptions.MaxNumberOfAttempts, same format

Tags flow through the existing
ScheduleTaskOptions.Tags → ScheduleTaskOrchestratorAction.Tags →
persisted TaskScheduledEvent.Tags pipeline. No dispatcher change.

This is the foundational change for the native activity retry visibility
feature.

Design

Counter is scoped to a single ScheduleWithRetry call (local variable
captured by the nested RetryCall function):

• Per-call-site counter — no shared state, no cross-call leakage.
• Replay-deterministic — RetryInterceptor.Invoke re-walks history the same
  way on replay, producing identical tag values.
• No infinite recursion — the recursive ScheduleTask<T> call passes
  options.RetryOptions == null, taking the non-retry path.
• dt.* tag prefix reserved for DTFx-injected metadata (no existing code or
  docs use it).

Files

• src/DurableTask.Core/OrchestrationContext.cs — ScheduleWithRetry
  closure builds ScheduleTaskOptions with the two tags.
• src/DurableTask.Core/RetryTags.cs (new) — internal constants.
• test/DurableTask.Core.Tests/ScheduleWithRetryTagsTests.cs (new, 360 lines)
  — covers monotonic counter starting at 1, per-call-site independence, replay
  determinism, Handle() short-circuit, InvariantCulture formatting,
  multi-digit attempts, maxAttempts=1.

Compatibility

• No API breaks.
• Backends that ignore TaskScheduledEvent.Tags (Azure Storage, MSSQL,
  Netherite) silently drop them at persistence.

[Copilot]

Pull request overview

This PR adds per-attempt retry metadata to OrchestrationContext.ScheduleWithRetry<T> by stamping reserved dt.retry.* tags onto each scheduled activity attempt, enabling downstream visibility tooling to identify retry attempt number and policy ceiling.

Changes:

• Inject dt.retry.attempt and dt.retry.maxAttempts tags into each ScheduleWithRetry activity scheduling attempt (formatted with InvariantCulture).
• Add RetryTags constants to centralize the reserved tag keys.
• Add unit tests intended to validate tag emission and behavior across various retry scenarios.

Reviewed changes

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

File	Description
src/DurableTask.Core/OrchestrationContext.cs	Adds per-attempt tag injection inside ScheduleWithRetry<T> via ScheduleTaskOptions.Tags.
src/DurableTask.Core/RetryTags.cs	Introduces reserved retry tag key constants (dt.retry.*).
Test/DurableTask.Core.Tests/ScheduleWithRetryTagsTests.cs	Adds tests validating retry tag emission (but currently placed under Test/, which is not part of the active test projects).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

[sophiatev]

Can we remove this part of the comment?

 /// where consumers (Functions extension, DTS Dashboard) can read them.
/// Backends that do not roundtrip <c>TaskScheduledEvent.Tags</c>
/// simply drop the tags at persistence; consumers fall back to a "metadata unavailable" path with no error.

I feel like it's leaking implementation details/we probably shouldn't be referencing Functions and DTS from here

[sophiatev]

Just double-checking, I'm assuming we confirmed this is actually true in testing (like a "live test", I see that we did test it in the unit tests)?

"deterministic replay reproduces the same per-attempt values because invokes the closure the same number of times in the same order on replay."

[sophiatev]

So if I understand this test correctly, we should never invoke the Activity in this case, right? I haven't looked at the other PRs yet so forgive me if we're already doing this but I wonder if we should add a check preventing a 0 value here since it seems non-sensical in that case...

[sophiatev]

One thing I just realized - will this work with rewind? I think it should be fine since we just delete the TaskScheduled events from the history that failed in that case, and the already-completed events should presumably be fine under replay... but maybe worth a check