Idempotency not working for delete

[Robin Williams]

Hi

I sent a delete request with an idempotency key, but it errored out the second time saying there was no such customer.  Here are the details:

Request:

stripe.customers.del(

  "cus_AhiUXu7Q0UZGbM",

  {

    idempotency_key: "customers.del.20170522160642960"

  }

)

First response:

{

  deleted: true,

  id: "cus_AhiUXu7Q0UZGbM"
}

Second response:

type: "StripeInvalidRequestError",

  stack: "Error: No such customer: cus_AhiUXu7Q0UZGbM

    at Error._Error (F:DevelopmentMEANSCRserver

ode_modulesstripelibError.js:12:17)

    at Error.Constructor (F:DevelopmentMEANSCRserver

ode_modulesstripelibutils.js:97:13)

    at Error.Constructor (F:DevelopmentMEANSCRserver

ode_modulesstripelibutils.js:97:13)

    at Function.StripeError.generate (F:DevelopmentMEANSCRserver

ode_modulesstripelibError.js:56:14)

    at IncomingMessage.<anonymous> (F:DevelopmentMEANSCRserver

ode_modulesstripelibStripeResource.js:147:39)

    at IncomingMessage.emit (events.js:117:20)

    at _stream_readable.js:944:16

    at process._tickCallback (node.js:442:13)",

  rawType: "invalid_request_error",

  code: undefined,

  param: "id",

  message: "No such customer: cus_AhiUXu7Q0UZGbM",

  detail: undefined,

  raw: {

    type: "invalid_request_error",

    message: "No such customer: cus_AhiUXu7Q0UZGbM",

    param: "id",

    statusCode: 404,

    requestId: "req_AhiUXBI7OvykHP",

    headers: {

      server: "nginx",

      date: "Mon, 22 May 2017 16:06:44 GMT",

      content-type: "application/json",

      content-length: "131",

      connection: "close",

      access-control-allow-credentials: "true",

      access-control-allow-methods: "GET, POST, HEAD, OPTIONS, DELETE",

      access-control-allow-origin: "*",

      access-control-max-age: "300",

      cache-control: "no-cache, no-store",

      idempotency-key: "customers.del.20170522160642960",

      request-id: "req_AhiUXBI7OvykHP",

      stripe-version: "2017-04-06"

    }

  },

  requestId: "req_AhiUXBI7OvykHP",

  statusCode: 404,

Help please.

Thanks

Robin

[Fred Alger]

Hi Robin,

Thanks for writing in about this! I've taken a look and confirmed the behavior you reported. At the present time, idempotency keys are not considered for DELETE requests. This doesn't seem reasonable given that DELETE requests also have side effects. We'll investigate on our end and will consider altering this behavior in the future. Meanwhile, I'd recommend ignoring any 404 error on subsequent deletions, as that indicates that the previous request deleted the object properly.

Hope that clears things up!

Best,

- Fred.

--
You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.
To post to this group, send email to api-d...@lists.stripe.com.
Visit this group at https://groups.google.com/a/lists.stripe.com/group/api-discuss/.

[Robin Williams]

Thanks Fred - I will implement that workaround for now.

Is there somewhere we have access to where details of fixes etc are posted?

The blog only seems to have very high level stuff.

[Fred Alger]

Hi Robin,

Just following up from yesterday—after further discussion, my mind has been changed and I actually agree with the current behavior. Discussing further with some other developers, it seems that DELETE is inherently idempotent: you can't DELETE what's already been deleted. Not to go too wild with RFCs, but DELETE is considered also idempotent on its own in the HTTP RFC:

https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2

> Methods can also have the property of "idempotence" in

> that (aside from error or expiration issues) the

> side-effects of N > 0 identical requests is the same as

> for a single request. The methods GET, HEAD, PUT and

> DELETE share this property. Also, the methods OPTIONS and

> TRACE SHOULD NOT have side effects, and so are inherently

> idempotent.

The fact that you can't see the "success" response returned from your first DELETE doesn't imply that the deletion didn't happen. In fact, the "404 Not Found" is telling you that the resource has been removed and retrying the DELETE will have no further effect. If you run N requests to DELETE a resource, the side effect of the resource being deleted will still happen exactly once, which meets the criteria for an idempotent action.

Our plan is to update the documentation and clarify the details with regard to non-POST requests. In the future, we might add a warning or error to let developers know that the idempotent key wasn't considered or appropriate for the request, but not without releasing a new API version.

As far as getting updates, there are two places:

https://stripe.com/docs/upgrades

And then there's the api-announce mailing list, which is currently a little out of date and being revised:

https://groups.google.com/a/lists.stripe.com/d/forum/api-announce

Hope the above is helpful!

Best,

- Fred.