We're updating the issue view to help you get more done. 

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

Environment

None

Assignee

Unassigned

Reporter

François Blackburn

Labels

Approvers

None

Pair

None

Sprint

None

Fix versions

None

Priority

Medium
Configure