Inconsistency about whether resuming a prompt should count as a retry

Version

master branch

Describe the bug

In Prompt.cs, ResumeDialogAsync calls RepromptDialogAsync which calls OnPromptAsync with isRetry set to false:

public override async Task RepromptDialogAsync(ITurnContext turnContext, DialogInstance instance, CancellationToken cancellationToken = default(CancellationToken))
{
    var state = (IDictionary<string, object>)instance.State[PersistedState];
    var options = (PromptOptions)instance.State[PersistedOptions];
    await OnPromptAsync(turnContext, state, options, false, cancellationToken).ConfigureAwait(false);
}

However, in ActivityPrompt.cs, RepromptDialogAsync calls OnPromptAsync with isRetry set to true:

public override async Task RepromptDialogAsync(ITurnContext turnContext, DialogInstance instance, CancellationToken cancellationToken = default(CancellationToken))
{
    var state = (IDictionary<string, object>)instance.State[PersistedState];
    var options = (PromptOptions)instance.State[PersistedOptions];
    await OnPromptAsync(turnContext, state, options, true, cancellationToken).ConfigureAwait(false);
}

I know it’s a rare case when a prompt would be resumed, but in such a case should the retry prompt be used or not?

[bug]

[Zerryth]

I made that change to RepromptDialogAsync(), specifically with the feedback from Gabo after he reviewed the PR to add isRetry onto ActivityPrompt.OnPromptAsync(), which you can see in the history here.

It’s specifically counting as a retry when re-prompting a user, so logically it made sense that it would go towards a retry count, and also aligned it in parity with JS (retries were completely missing from C# ActivityPrompt prior to the PR linked).

• Additionally, the ActivityPrompt class was just admittedly “weird” in comparison to the other “Prompts”, as it is in Microsoft.Bot.Builder.Dialogs namespace and does not derive from Prompt class, but instead directly from Dialog.
• Furthermore, deriving directly from Dialog, it’s the only one you’ll see that overrides the Dialog.RepromptDialogAsync() method

---

I know it’s a rare case when a prompt would be resumed

• Given that it is re-prompting the user, I still agree with Gabo’s feedback and think that it should in fact count as a retry
  • It’s not simply just a “resume” on a prompt, implying it might’ve gone away to take care of something else first, before continuing where it had left off
  • Although it is called by ResumeDialogAsync()
    • Hmm…but the class is abstract, so ultimately user could override their ResumeDialogAsync() to call RepromptDialogAsync() how they’d prefer
    • Admittedly I do see the oddness this brings when Resume calls Reprompt
• That, and to remain in parity with what we had in the other language SDKS.

---

Thoughts, @gabog ?

[v-kydela]

Here’s a real-world example of a prompt being resumed: https://stackoverflow.com/questions/64765378/textprompt-reprompts-after-interruption