race condition cause traceback during wazo-chatd initialization
Description
Given I have a very long initialization process of wazo-chatd When I have an DeviceStateChange event received during init Then I can have some weird traceback in log:
Expected: no traceback Workaround:
nothing (because state will be updated on the next event)
restart wazo-chatd
Real scenario: It can happen when you restart your server and the phone change their state during wazo-chatd start and the init takes many seconds
Ideas: Add a lock during init process to avoid to process events. But process this event after init process IF the event is received between the amid response of all devices state AND the end of the init. It will minimize error of state after init
Given I have a very long initialization process of wazo-chatd
When I have an DeviceStateChange event received during init
Then I can have some weird traceback in log:
Expected: no traceback
Workaround:
nothing (because state will be updated on the next event)
restart wazo-chatd
Real scenario: It can happen when you restart your server and the phone change their state during wazo-chatd start and the init takes many seconds
Ideas:
Add a lock during init process to avoid to process events. But process this event after init process IF the event is received between the amid response of all devices state AND the end of the init. It will minimize error of state after init