[asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error

[Kevin Harwell]

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



./asterisk/trunk/tests/rest_api/applications/stasis_status/ari_client.py
<https://reviewboard.asterisk.org/r/4520/#comment25395>

    Is this method used someplace? If so I just missed it, if not then it can be removed.



./asterisk/trunk/tests/rest_api/applications/stasis_status/ari_client.py
<https://reviewboard.asterisk.org/r/4520/#comment25396>

    I would opt for the python convention of "easier to ask forgiveness..." and wrap this in a try/except block instead.



./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/sip.conf
<https://reviewboard.asterisk.org/r/4520/#comment25404>

    Convert this to use pjsip instead.



./asterisk/trunk/tests/rest_api/applications/stasis_status/observable_object.py
<https://reviewboard.asterisk.org/r/4520/#comment25399>

    This function seems unused. If it is not needed it can be removed.



./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml
<https://reviewboard.asterisk.org/r/4520/#comment25400>

    Looks like there are 5 ways :-)



./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml
<https://reviewboard.asterisk.org/r/4520/#comment25401>

    13.3.0-rc1 was just release, so I believe this should be 13.4.0



./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml
<https://reviewboard.asterisk.org/r/4520/#comment25402>

    A dependency needs to be added for the asterisk channel driver you are using so a conflict won't occur.



./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py
<https://reviewboard.asterisk.org/r/4520/#comment25403>

    A lot of the code in this object as well as others (AriClient, ObservableObject) looks similar to much of the code found in the AriTestObject or AriBaseTestObject.
    
    I'm thinking you can inherit instead from one of those two ARI test objects and simplify things greatly, overriding/adding methods where needed. You might even be able to get away with using the WebSocketEventModule and handling things like adding a channel to a bridge or disconnecting the websocket in raised callbacks. At least for a couple of these scenarios. For that though you would have to break the scenarios into separate tests.


- Kevin Harwell


On March 22, 2015, 11:34 p.m., Ashley Sanders wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4520/
> -----------------------------------------------------------
> 
> (Updated March 22, 2015, 11:34 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24802
>     https://issues.asterisk.org/jira/browse/ASTERISK-24802
> 
> 
> Repository: testsuite
> 
> 
> Description
> -------
> 
> When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis).
> 
> This patch introduces a new channel variable: STASIS_STATUS to give outside applications context when errors occur in Stasis that interrupt normal processing.
> 
> This test exercises three scenarios to elicit updates to the STASIS_STATUS channel variable:
> 1) The 'Babs' scenario: tests a nominal path of Stasis to verify the 'ACTIVE' state is correctly applied. For this test, a call is originated under normal conditions and then the system is polled for the value of STASIS_STATUS before the channel is hung up.
> 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied.
> 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied.
> 
>  ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/
> 
> 
> Diffs
> -----
> 
>   ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario.py PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/run-test PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/observable_object.py PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/sip.conf PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/http.conf PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/extensions.conf PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/ari.conf PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/ari_client.py PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/4520/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Ashley Sanders
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150324/e8e65636/attachment-0001.html>