Adds X-Parse-Push-Status-Id header

[flovilmart]

fixes #1157

[flovilmart]

I understand that's not super nice, but I didn't want to break the returned promise that allow us to test the push flow.

Open to suggestions

[codecov-io]

Current coverage is 92.77%

Merging #1412 into master will increase coverage by +0.03% as of e037011

@@            master   #1412   diff @@
======================================
  Files           86      86       
  Stmts         5433    5442     +9
  Branches      1004    1005     +1
  Methods          0       0       
======================================
+ Hit           5039    5049    +10
  Partial         10      10       
+ Missed         384     383     -1

Review entire Coverage Diff as of e037011

Powered by Codecov. Updated on successful CI builds.

[drew-gross]

This seems reasonable given the constraints, but shouldn't the POST handles be waiting to respond until after the sendPush function is done anyway?

[flovilmart]

That can be long, and defeats the purpose of the push status... Open to change it though but that will impact negatively the performance, I don't believe parse.com was waiting for it to be done.

[drew-gross]

Hmmm I'm not super familiar with the model we are using here, it must be different from Parse.com. In Parse.com we write a push status object, then read from it to actually send the push. We respond to the request once the push status object is written, not when the push has finished. Is that not how it works here?

[flovilmart]

we don't wait for anything in that case. I could wait for the initial _PushStatus to be stored before calling back.

[drew-gross]

I think this makes more sense. It's too bad we rely on the result of the long-running promise, or we could return the earlier promise. Can you call your callback function onPushStatusSaved or something similar instead? Other than that this looks good now.

[flovilmart]

waiting for travis then merging

[facebook-github-bot]

@flovilmart updated the pull request.