[LRUG] Double submit

[Srushti Ambekallu]

The way this manifested for us was iOS Safari not getting a confirmation of the first POST because of a spotty connection, and deciding to submit again (we disable the button on the first submit, so a double-click is less likely for us). As part of the API design, we request the consumers to send a unique transaction ID (a UUID, probably). We started out by failing on a duplicate transaction, but we’re not moving towards returning the response of the first request in the second.

We will probably use redis or something similar to temporarily store these responses for a couple of minutes or so.

I mentioned our solution in the context of the API specifically, because we have third party consumers of our API, as well as our own single-page Angular app and mobile apps which speak directly to the API.

----
Thanks,
Srushti

> On 25-Apr-2015, at 01:12, Andrew Stewart <boss at airbladesoftware.com> wrote:
> 
> Thanks, everyone, for all the suggestions.
> 
>> Tom:
>> I assume we’re talking about a POST request that has side effects that shouldn’t be repeated, like sending an email or creating a row in a database table.
> 
> Yes, that's exactly what I'm talking about.
> 
> I hadn't thought of debouncing the side-effects instead of the requests.  Presumably one would have to explicitly code this in wherever necessary.  In contrast a middleware approach could apply to all POSTs.
> 
>> Rob:
>> ... in the event of a double-click, it's the second submission that the user will actually see. If you're showing something useful on the confirmation page (even just the confirmation itself), you don't want to lose that in favour of a validation message.
> 
> That seems like a fairly crucial point – does it always hold?  No matter whether we somehow ignore the second POST or debounce its side-effects, we want the user to see the result of the first POST.
> 
> I think I'll experiment a little and see how things shake out.
> 
> Bon weekend!
> 
> Andy
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org