Jesse Storimer <[email protected]> wrote: > It seems that in this case the Rails app actually aborts the request, > wherever it is in the course of it. The issue I ran into is that my app > made a destructive request to an external service in > the context of a request, but the client disconnected before the app was > able to respond. So the external service returned its response but the > request was aborted before the app was able > to commit its transaction to the database, confusion ensued.
You should make this request to the external service and wait for this response inside state 3) as described in my other reply[1]. If you're affected by state 2), you should minimize the time in state 2) by using PrereadInput middleware to jump to state 3) (and you'll avoid making the external request entirely if the preread input fails due to the client aborting). Your goal is to minimize the time spent processing a non-idempotent request/parts-of-the-request and isolate where a client can fail (and maximize the time where they can gracefully recover). If possible, the request you make to the external service should be idempotent, but it doesn't seem to be... I haven't encountered this problem myself in many years, but here's what I did in the past for similar problems: Call the external service asynchronously and look at the various background job/queue libraries available to handle this. The client should probably auto-refresh on a page (idempotently) until the async request is complete. I would even hold off on starting your external request until the client has hit the auto-refresh page. This way you know the client has started the refresh cycle and you can fake the idempotency of the external request on your app side. [1] - http://mid.gmane.org/[email protected] -- Eric Wong _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
