Skip to content

feature: retrying sends with an optional delay#404

Open
Nolab0 wants to merge 6 commits intomainfrom
384-re-queue-a-failed-send
Open

feature: retrying sends with an optional delay#404
Nolab0 wants to merge 6 commits intomainfrom
384-re-queue-a-failed-send

Conversation

@Nolab0
Copy link
Member

@Nolab0 Nolab0 commented Feb 11, 2026

Close #384

@Nolab0 Nolab0 requested a review from supun-io February 11, 2026 16:06
@codecov-commenter
Copy link

codecov-commenter commented Feb 11, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@supun-io supun-io changed the title Add send retyring with optional delay feature: retrying sends with an optional delay Feb 27, 2026
Copy link
Member

@supun-io supun-io left a comment

Choose a reason for hiding this comment

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

great! while testing, I thought of a couple of improvements we can add:

  • remove "Schedule Retry" button and only have "Retry" button. It will open a modal.
  • in the modal user can
    • select which recipients to retry (send this to endpoint)
    • select "Now" or "Schedule" from a radio button (add a datetime input for that)
  • update the input for that
  • add a "Try now" button for the QueuedCallout:
Image

We can probably reuse the same endpoint for this.

  • Move the FailedCallout to its own component like QueuedCallout

@supun-io supun-io force-pushed the 384-re-queue-a-failed-send branch from 461ee6c to db838fb Compare March 4, 2026 10:18
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.

Re-queue a failed send

3 participants