Skip to content

Not informing ServicePulse users about “Edit & retry” failure #5122

@bartekwasielak

Description

@bartekwasielak

Describe the suggested improvement

Is your improvement related to a problem? Please describe.

There is a failed message. The user wants to use the “Edit & retry” feature on it. In some conditions the “Edit & retry” attempt might fail. In that case the ServicePulse user sees:

  1. A toast notification informing about retrying the message, that disappears after a few seconds:
Image
  1. A Processed label:
Image

That message is never processed though, and there is a an entry in the ServiceControl’s log:
2025-09-23 11:19:15.8610|00:23:50.191|52|Warn|ServiceControl.Recoverability.Editing.EditHandler|Discarding edit & retry request because the failed message id edb88e88-a99f-c66f-ac6b-7ad34d0b8cfe has already been edited by Message ID 2f2f5b22-3671-4287-9e09-b36100fc70de

The user might be misled to think that their attempt was successful.

This can happen in the following scenarios:

  1. After having retried the message, the user very quickly clicks on the still active “Edit & retry” button, clicks “Yes”, and then “Retry”. (seems very unlikely).
  2. A user opens the failed message’s details page in two tabs or browsers, edits and retries it from the first tab, and then edits and retries it from the second tab.
  3. Two users concurrently review the failed message’s details page and edit and retry it.

Describe the suggested solution

On top of logging the warning in ServiceControl, a message in ServicePulse would be displayed.

Eliminating scenario 1. from above is also possible by disabling the “Edit & retry” button immediately after the message has been retried (in the same browser tab).

Describe alternatives you've considered

Blocking the “Edit & retry” button in all open browsers through SignalR immediately after the message has been retried. Potential issues:

  1. Some complexity of implementing this solution (there are three steps with three different buttons required for running the edit and retry).
  2. Because of some SignalR delay, this wouldn’t eliminate the problem fully, but decrease its probability of happening.

Additional Context

No response

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions