PANIC Alerter currently keeps the same mapping when no configs are recieved.
'To be' behaviour
When a channel is either deleted/removed from a configuration, the router must not include this mapping in the configuration.
Steps to reproduce
1) Created a valid Substrate Polkadot chain on PANIC with a single valid Slack configuration.
2) Started getting alerts, so works as intended.
3) Removed the channel from this config.
4) alert_router.log still shows the following after recieving a new alert:
19/10/2022 01:46:28 PM - AlertRouter - INFO - ['634fff30a7d1b84a6b792d88']
19/10/2022 01:47:18 PM - AlertRouter - INFO - Obtaining list of channels to alert
19/10/2022 01:47:18 PM - AlertRouter - INFO - ['634fff30a7d1b84a6b792d88']
19/10/2022 01:49:38 PM - AlertRouter - INFO - Obtaining list of channels to alert
19/10/2022 01:49:38 PM - AlertRouter - INFO - ['634fff30a7d1b84a6b792d88']
Steps to fix
[ ] Investigate the alert_router.py logic in full
[ ] Debug
[ ] Find and implement a fix
[ ] Test
Acceptance criteria
Given: PANIC running with a configuration including a channel
When: Channel removed from the config
Then: Alert router receives the correct updated mapping
itsciccio
commented
1 year ago
Summary of bug
'As is' behaviour
PANIC Alerter currently keeps the same mapping when no configs are recieved.
'To be' behaviour
When a channel is either deleted/removed from a configuration, the router must not include this mapping in the configuration.
Steps to reproduce
1) Created a valid Substrate Polkadot chain on PANIC with a single valid Slack configuration. 2) Started getting alerts, so works as intended. 3) Removed the channel from this config. 4)
alert_router.logstill shows the following after recieving a new alert:Steps to fix
alert_router.pylogic in fullAcceptance criteria
Given: PANIC running with a configuration including a channel When: Channel removed from the config Then: Alert router receives the correct updated mapping