[asterisk-dev] [Code Review] 3217: pjsip/subscribe/missing_aor: Fix test by using MessageWaiting AMI event

[Matt Jordan]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3217/
-----------------------------------------------------------

Review request for Asterisk Developers and Kevin Harwell.


Repository: testsuite


Description
-------

The pjsip/subscribe/missing_aor has been failing consistently on the 32-bit build agent. Interestingly, it has been passing on the much slower 64-bit build agent (the CPU architecture here is a red herring - the 64-bit build agent is running on the crappiest hardware we have. On purpose. Slow things catch problems!)

The reason why is due to how the test was written. Each step in the test is triggered on the success of the previous step, where the previous step was typically an AMI action execution. However, the AMI actions for updating external MWI occur when the Stasis message for modifying the mailbox state has been created and dispatched, not when the core has actually bothered to update the MWI. Hence, the test was running through its various AMI actions and then sending the SIP SUBSCRIBE request before all of the mailbox state had been updated.

On the fast build agent, this typically failed. On the slow build agent, it typically succeeded due to Asterisk actually running faster than the test python script.

This patch refactors the test to use the AMI event MessageWaiting to trigger the next stage. The AMI event is raised when the core itself has actually updated the mailbox, so the test knows for sure that the mailboxes are in the correct state before it subscribes.


Diffs
-----

  /asterisk/trunk/tests/channels/pjsip/subscribe/missing_aor/run-test 4701 

Diff: https://reviewboard.asterisk.org/r/3217/diff/


Testing
-------


Thanks,

Matt Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140213/22748b24/attachment.html>