Intro
We operate a web app that allows users to still update the state of the database while they’re offline, trusting that everything will get synced up by Meteor once they reconnect. But recently we noticed an issue with the handling of method calls by the server.
Issue
When a client disconnects before a response to a method call is received, the client side correctly puts it in the retry bin. The problem arises on the server side. It gets the method call and begins executing (changing the db, etc). When the time comes to send the response back, the client has disconnected. When the client reconnects, the same request is sent again (correctly, because the client didn’t know if the method was successful or not), but it also gets executed by the server again. For db inserts this is not that a big of a deal since it will just fail on a duplicate key error, but the handling db updates twice broke some aspects of our application.
Versions
We only recently came aware of this issue so we were also wondering if this was maybe a regression in Meteor, or if this has always worked this way. We noticed the issue on v2.2 and checked if it was still present on older versions. It seems that version 1.11 also behaves the same.
Reproducing steps
- Create a new meteor method that logs something to the console
- Create a script that calls this method and immediately disconnects (Meteor.disconnect())
- See that the server logs something to the console
- Let the server finish executing the method
- Reconnect the client (Meteor.reconnect())
- See that the server logs the same thing again
Possible solution
The problem arises because the server doesn’t keep track of the methods it already has executed. A possible solution would be saving the method responses when they couldn’t be sent back to the client and sending them when the client reconnects and performs the method call again.
Did anyone experience the same issue and/or is it already noted somewhere?