Can't tell when code inside Meteor.defer has finished

testing
1

I’m writing integration tests for my meteor project. I want to test the webhook POST handler in my app. This is how it looks like:

post() {
  Meteor.defer(() => {
    // some logic here, e.g insert / update database
  })
  return {
    statusCode: 200,
  }
}

Note: I use Meteor.defer here because I want to return code 200 (OK) as soon as possible.
To test this webhook, I create a fake POST request to this webhook, then check if the database is updated accordingly. The problem is that in the test I don’t know when the code inside Meteor.defer has finished, therefore my assertions are failed because the database hasn’t been updated yet.
Any suggestions ?

1 Like
2

simply don’t use defer here. You also don’t want to return 200 if you’re logic had some error.

3

My webhook will be called by a 3rd party (Facebook, in this case) so I need to return 200 asap otherwise Facebook will send another request.
By the way, I came up with a work around for this problem: use mocha’s test timeout (so assertions will be run after a specific amount of time). It’s ugly but it works at the moment.

4

What does the “ASAP” mean here? Because a POST that includes something with the users collection should not take long (max 500ms in extreme cases). Facebook should not have a timeout that is that short.

2 Likes
5

Sorry for not being clear, in my logic sometimes it may take up to >= 10 seconds to calculate a reply (calculation that performs on very large arrays), that’s why I try to response 200 to Facebook as soon as possible (= telling Facebook that our webhook got the request, Facebook doesn’t need to resend this request) and then later on, calculate a reply + send this reply to users.

6

Ah. If you can’t solve by making it synchronous. Why don’t you create a small queuing mechanism? Simply push the request to a queue, tell Facebook that things were alright and then process the item from the queue using another mechanism.

In your test you can test the 2 parts separately. Basically its a Producer consumer pattern

2 Likes