Summary:	ASTERISK-28679: stasis application is destroyed after its creation
Reporter:	Francois Blackburn (fblackburn)	Labels:
Date Opened:	2020-01-06 10:52:02.000-0600	Date Closed:	2020-01-30 10:03:19.000-0600
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Resources/res_ari
Versions:	16.7.0	Frequency of Occurrence	Constant
Related Issues:	is caused by ASTERISK-28423 ARI causes STASIS Deadlock
Environment:	Debian buster	Attachments:
Description:	Given I create bridge (type=holding) Given I create Stasis application (by connecting the websocket) Given I subscribe the bridge to the application Given I close the websocket connection Given I destroy the bridge When I reconnect the websocket When I get the application with ARI Then I get 404 application not found Expected I get the application I have the following log for my last websocket connection : {code} [Jan  6 09:00:22]  Activating Stasis app 'MY_APPLICATION' [Jan  6 09:00:22]   == WebSocket connection from '127.0.0.1:49876' for protocol '' accepted using version '13' [Jan  6 09:00:22]  Destroying Stasis app MY_APPLICATION [Jan  6 09:00:22]     -- Remove stasis-MY_APPLICATION/h/1, registrar=res_stasis; con=stasis-MY_APPLICATION(0x7fd5f000fe70); con->root=0x7fd5f00102a0 [Jan  6 09:00:22]     -- Remove stasis-MY_APPLICATION/_./1, registrar=res_stasis; con=stasis-MY_APPLICATION(0x7fd5f000fe70); con->root=0x7fd5f00102a0 {code} This bug has been introduced by [this commit|https://gerrit.asterisk.org/c/asterisk/+/13172]. e.i. I cannot reproduce it if I revert this one I've created a small python script to trigger this bug https://gist.github.com/fblackburn1/b945798b882bc825db2c2258174cad0e
Comments:	By: Asterisk Team (asteriskteam) 2020-01-06 10:52:03.569-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. By: Kevin Harwell (kharwell) 2020-01-08 09:40:02.083-0600 Confirmed using the given steps. It appears it may have something to do with the deleting of a bridge that's been subscribed to by the application. I tried a few other combinations of disconnecting/reconnecting the application and it seemed to find it. In some cases the "GET /applications/{applicationName}" command even return "okay" when disconnected. It seems to be that deleting the bridge, and then upon reconnection Asterisk "loses" application. By: Kevin Harwell (kharwell) 2020-01-08 09:43:43.620-0600 Oh and I also removed the patch mentioned to have caused this behavior, and things did seem to work. But even with the patch removed Asterisk seems to keep track of the application even when not connected as  "GET /applications/{applicationName}" returned "okay" even though the application had disconnected (probably a different bug though). By: Friendly Automation (friendly-automation) 2020-01-30 10:03:20.689-0600 Change 13675 merged by Friendly Automation: res_stasis: trigger cleanup after update [https://gerrit.asterisk.org/c/asterisk/+/13675|https://gerrit.asterisk.org/c/asterisk/+/13675] By: Friendly Automation (friendly-automation) 2020-01-30 10:03:42.184-0600 Change 13697 merged by Friendly Automation: res_stasis: trigger cleanup after update [https://gerrit.asterisk.org/c/asterisk/+/13697|https://gerrit.asterisk.org/c/asterisk/+/13697] By: Friendly Automation (friendly-automation) 2020-01-30 10:04:42.382-0600 Change 13698 merged by Friendly Automation: res_stasis: trigger cleanup after update [https://gerrit.asterisk.org/c/asterisk/+/13698|https://gerrit.asterisk.org/c/asterisk/+/13698] By: Friendly Automation (friendly-automation) 2020-01-30 10:20:30.830-0600 Change 13696 merged by George Joseph: res_stasis: trigger cleanup after update [https://gerrit.asterisk.org/c/asterisk/+/13696|https://gerrit.asterisk.org/c/asterisk/+/13696] By: Friendly Automation (friendly-automation) 2020-01-30 10:22:03.677-0600 Change 13719 merged by George Joseph: res_stasis: trigger cleanup after update [https://gerrit.asterisk.org/c/asterisk/+/13719|https://gerrit.asterisk.org/c/asterisk/+/13719] By: Friendly Automation (friendly-automation) 2020-01-30 10:22:42.422-0600 Change 13720 merged by George Joseph: res_stasis: trigger cleanup after update [https://gerrit.asterisk.org/c/asterisk/+/13720|https://gerrit.asterisk.org/c/asterisk/+/13720] By: Friendly Automation (friendly-automation) 2020-01-30 10:23:16.117-0600 Change 13741 merged by George Joseph: res_stasis: trigger cleanup after update [https://gerrit.asterisk.org/c/asterisk/+/13741|https://gerrit.asterisk.org/c/asterisk/+/13741]