Users of this package have the ability to call respond() inside a handler before the handler function has returned. That means that someone may accidentally try updating an interactive message before the interactive message has even been acknowledged (because the handler returning is the signal that we can respond with 200 OK). If the respond() function waited until the next tick to do any work, then the handler function's return would always be before the request to the response_url, and it would prevent these types of issues.
Disclaimer: we're still not sure this was the actual problem with the issue mentioned above.
Requirements
[x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
Description
Inspired by #68.
Users of this package have the ability to call
respond()
inside a handler before the handler function has returned. That means that someone may accidentally try updating an interactive message before the interactive message has even been acknowledged (because the handler returning is the signal that we can respond with200 OK
). If therespond()
function waited until the next tick to do any work, then the handler function's return would always be before the request to theresponse_url
, and it would prevent these types of issues.Disclaimer: we're still not sure this was the actual problem with the issue mentioned above.
Requirements