----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3361/#review11296 -----------------------------------------------------------
Ship it! Looks good other than the description and comment changes below. /asterisk/trunk/tests/rest_api/applications/subscribe-bridge/subscribe_bridge.py <https://reviewboard.asterisk.org/r/3361/#comment20938> s/testsuite/bridge-watching-app/ /asterisk/trunk/tests/rest_api/applications/subscribe-bridge/test-config.yaml <https://reviewboard.asterisk.org/r/3361/#comment20939> s/It that/It/ - opticron On March 14, 2014, 4:23 p.m., Matt Jordan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3361/ > ----------------------------------------------------------- > > (Updated March 14, 2014, 4:23 p.m.) > > > Review request for Asterisk Developers, David Lee, Joshua Colp, and kmoore. > > > Repository: testsuite > > > Description > ------- > > The change in r410528 (https://reviewboard.asterisk.org/r/3336/) introduced a > subtle behaviour change that broke the rest_api/bridges/subscription test. > Previously, the test did the following: > > * Create a Stasis application 'testsuite' > * Create a Stasis application 'bridge-watching-app' > * POST a channel to application 'testsuite' > * POST a bridge > * Subscribe application 'bridge-watching-app' to the bridge > * Add the previously posted channel to the bridge > ** Verify that the app 'testsuite' sees the bridge update (as its channel is > in the bridge) > ** Verify that the app 'bridge-watching-app' sees the bridge update (as it > was subscribed) > * Unsubscribe the app 'testsuite' from the bridge > * Remove the channel from the bridge > ** Verify that the app 'bridge-watching-app' see the bridge update > ** Verify that the app 'testsuite' does NOT see the bridge update > <------------ THIS IS NOW BROKEN > > The last verification broke because we now ensure that applications who have > channels in a bridge are now subscribed implicitly to the bridge while their > channel is in it. You can now no longer unsubscribe from the implicit > subscription created by your channel: you may decrement the subscription > count, but it won't be sufficient to nuke out the subscription that ARI has > created for you. > > I actually think this behaviour change is a good thing: If you have a channel > in an application, and it is doing "things", you should always be notified of > the "things" it is doing. Even if you claim you don't want to know - > otherwise, how do you know when you can DELETE the channel? Or do something > else crazy to it? > > This test has now been updated so that the thing unsubscribed is the > 'bridge-watching-app'. This still verifies subscribes/unsubscribes - but it > does so where the entity subscribing for the bridge updates never had a > 'stake' in the state of the bridge in the first place. > > > Diffs > ----- > > > /asterisk/trunk/tests/rest_api/applications/subscribe-bridge/test-config.yaml > 4844 > > /asterisk/trunk/tests/rest_api/applications/subscribe-bridge/subscribe_bridge.py > 4844 > > Diff: https://reviewboard.asterisk.org/r/3361/diff/ > > > Testing > ------- > > > Thanks, > > Matt Jordan > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev