Ability to resend an event

[Maxime]

Is your feature request related to a problem? Please describe.

With Stripe CLI, we can resend an event easily.

With the Stripe Java API, I'd like to have the same ability.

In order to write a test to make sure that our webhook enpoint handling events is fully idempotent, I wanted to write a test that'd replay an event and assert accordingly. It's not possible with this SDK.

Describe the solution you'd like

Just like we can call Customer.create for example, it'd be nice to have an Event.resend method where we'd pass the ID of the event to emit again.

Describe alternatives you've considered

Running the Stripe CLI from the java code as a quick workaround or call the API directly. But it's really not ideal of course.

Additional context

Just to emphasize a little bit on this, looking on StackOverflow, I found out this question which so far has 18 upvotes. While it's not specifically asking for support in the Java SDK, it clearly shows the overall interest in the resend mechanism.

[Maxime]

In case that helps anyone else, meanwhile I'm doing this:

// this should be removed once a proper method is implemented
// https://github.com/stripe/stripe-java/issues/1557
suspend fun retryEvent(
    eventId: String,
) {
    val httpClient = HttpClient(CIO)

    // this event is not even in the doc
    // https://stripe.com/docs/api/events/types
    // but we can find it from the code of the CLI
    // https://github.com/stripe/stripe-cli/blob/2bf13c1dbc2a3be683d16a54d3e06a0f9e7ed585/pkg/cmd/resource/events_resend.go#L31
    httpClient.post("https://api.stripe.com/v1/events/$eventId/retry") {
        headers {
            append(HttpHeaders.Authorization, "Bearer ${Stripe.apiKey}")
        }
    }

    httpClient.close()
}

[Richard Marmorstein]

Hello @maxime1992, thank you for the feature request.

I'm a bit skeptical of this, and I want to understand your use case better.

Right now/v1/events/$eventId/retry is intended for one-off use cases only. We don't intend for it to be called programmatically. That's why it's not public.

For example, the Stripe CLI and the Stripe Dashboard have the "retry event" capability for use cases like:

• an event happens
• your integration has a bug and crashes
• you fix your code and want to reprocess the event

This can happen during development -- when you are iterating on your event handling logic to get it right -- and possibly also in production when you discover a bug, or your server goes down, and you need to do some one-off reprocessing. In these contexts, the application is crashing or being restarted, and so it is necessary for the replay functionality to be provided by Stripe.

Inside your application's test suite, by contrast, it should be straightforward (not to mention more robust and faster) to intercept the webhook payload and send it twice through your application's event handler, instead of needing to request retransmission all the way from Stripe.

[Zak Henry]

Hi @richardm-stripe (for context I am @maxime1992's colleague)

We certainly could make our idempotency test lower level and not interact with Stripe API at all which we will do, however I don't fully agree with there being no good use cases for programmatic access. As you explain it is an expected interaction with Stripe to have the dashboard dispatch events using a retry mechanism, so it is reasonable for our full stack tests to verify this behaviour works as intended with our integration.

---

Your example of the production bug is also a valid use case.

The scenario could be that our webhook service is down for some reason and so misses a bunch of events. We should know the time period of the downtime so would want to write a script that replayed the events in that period using https://stripe.com/docs/api/events/list (with some overlap for good measure). Our intention is to write this script ahead of time in the (hopefully unlikely) event that we have some down time disaster recovery will be helped by the existence of this already existing test script.

This script could be written using bash and the stripe cli, but it feels reasonable to want to do that in a more type safe language like Java (or Kotlin in our case).

[Richard Marmorstein]

Hi @zakhenry, thank you for the thoughtful response. I appreciate the detailed information about your use case. I'll discuss this with my colleagues internally and try and get back to you soon.

I may end up closing this ticket as it is really a feature request for the Stripe API to make /v1/events/$eventId/retry a public endpoint, and can't be actioned/tracked as a feature request for stripe-java. For it to be correctly tracked you should open up a ticket with Stripe Support

[Zak Henry]

OK done, (confirmation email ref #em_cy25ktm7o3qfosdthxgn6kjv8trxim)

[Richard Marmorstein]

I wanted to confirm that we are now internally actively tracking the feature request for /v1/events/$eventId/retry to be made public, but I don't have any information on when/whether this would be prioritized.

I am closing the issue here as "not planned" as it doesn't represent outstanding work for stripe-java in particular, but I will make sure to leave an update if the team does end up making the endpoint public.