DoSomething/ds-mdata-responder — pull request #173 by tongxiang (2014-09-19 19:33:50+00:00)
Title: Story config invalid fix

## What's this PR do?
Moves the **response.send()** to be inside the gameDocument. Fixes the 'story config invalid' error message propagated by Mobile Commons (see below for a more thorough explanation of the problem.)

## How should this be manually tested?
Tested locally with Postman, but hard to replicate the issue without a pre-populated, large database. Future tests should be run on a duplicated database.

## Any background context you want to provide?
As our MongoDB databases continue to fill up, we keep on receiving error messages from Mobile Commons that our server returns a 500 HTTP code and the message "server configuration invalid", thrown when an alpha first creates a multiplayer game and then creates an alpha-solo game.In other words, this happened to a user who 1) invited friends to play the game, 2) after invitation received the ‘SOLO’ solicitation message almost immediately, 3) texted “SOLO”, 4) got the first message, texted back ‘A’, and got the story configuration invalid message.

###High level:
This was happening because of a series of disordered asynchronous database calls.

###Low level:
Our own alpha-solo game creation route works by POSTing to the **/sms-multiplayer-game** route with empty strings in the beta properties, and then by POSTing again to the **/alpha-start** route. Because the **.gameCreate()** function (ran by the multiplayer game creation route) in the competitive story controller previously fired the **response.send()** function outside of any of the Mongoose (MongoDB ORM) callbacks making database calls, the response has been occasionally firing before the Mongoose calls have returned.

Thus, the **/alpha-create** route may occasionally have been hit before the alpha's userModel document was edited to show that she had been moved *out of the multiplayer game* and *into the solo game.* That caused the players_current_status property of the alpha-solo game doc to be empty (and not updated with the first opt in path). Hence, while the alpha may have been able to have been opted into the first message in the game, if she responded, her response would've been parsed but the controller *would not have been able to opt her into her next opt in path because the gameDoc wouldn't have been updated with her current status.*

This PR fixes this issue by placing the response.send() message within the callback of the Mongoose function updating the alpha game doc.

For Tong's (rather disjointed) notes on this error message, check out [this](https://www.evernote.com/shard/s114/sh/fcec6ba9-4dc6-4914-b982-a2d0bd0c0548/9e62079510660c66898d702eba7da15d) Evernote note.

## What are the relevant tickets?
Jira SMS-81