Multiple channel managers are being created

[TonyGiorgio]

In VSS:

SELECT store_id, key, version, created_date, updated_date
FROM vss_db 
WHERE store_id = '02cde81540c6627234edc48575dc938326b8bd34d7bcd777dc6e9c1ab758b93127';

Will produce a few managers, and one channel monitor that goes for one of them:

monitors/..._4223775b-2702-4a65-88d8-8af82cc33e65

manager_53c86ce2-24f5-49c4-aa70-cd666c5d3e11
manager_7d5bf56a-e938-4aac-9ac3-a0653126ea81
manager_4223775b-2702-4a65-88d8-8af82cc33e65
manager_9eef7c5d-5416-469f-a8ed-7ec5fdf1ef58

This is causing the manager with 9eef7c5d-5416-469f-a8ed-7ec5fdf1ef58 to be loaded, and it's not finding the monitors for 4223775b-2702-4a65-88d8-8af82cc33e65.

1. We need to know how this happened and what to do to prevent this from happening.
2. We need to know what to do to fix this for the user.

MutinyWallet/mutiny-web#889

[benthecarman]

This seems like a symptom of the double init issue

We need to know how this happened and what to do to prevent this from happening.

#1039 will make it so even if we double init it won't create separate instances in storage of the same node.

One of the changes in #1017 was to create the first node in the background to make the first load faster. Maybe we should revert this as it only happens once so it isn't the end of the world for taking a little longer.

We need to know what to do to fix this for the user.

In their logs it has initializing a new node: 9eef7c5d-5416-469f-a8ed-7ec5fdf1ef58 which means its initializing the node but not finding its manager/monitors because its looking under the wrong uuid. Best way to fix would be to edit the state file to point to the right uuid.

[TonyGiorgio]

There are 20 cases of this happening, with 4 cases where the channel might not be okay (3 others from the known case)

#	store_id	count
1	02ca7..	2 - 2023-12-22 seems okay (chan last used 2-19)
2	0361..	2 - 2023-09-25 no channel 
3	020..	2 - 2024-01-09 not okay (chan last used before duplicate)
4	03b61..	2 - 2023-12-18 no channel
5	031ac..	2 - 2023-12-18 no channel
6	02cd..	4 - 2024-02-16 not okay (known case)
7	0309..	2 - 2023-09-25 no channel
8	02369..	2 - 2024-02-19 no channel
9	027..	2 - 2023-11-30 no channel 
10	02711..	2 - 2024-01-22 no channel
11	039..	2 - 2024-02-19 seems okay (chan created with most recent manager)
12	02c4..	2 - 2023-12-11 no channel
13	035..	2 - 2024-02-18 not okay (chan last used before duplicate)
14	02e..	2 - 2024-02-15 no channel
15	02b..	2 - 2023-12-18 no channel
16	03b0..	2 - 2023-11-21 seems okay (chan created with most recent manager)
17	030..	2 - 2024-02-18 no channel
18	030..	2 - 2024-02-18 not okay (chan last used before duplicate)
19	026..	2 - 2023-09-25 no channel
20	035f9..	2 - 2023-09-25 no channel

[benthecarman]

Hmm okay, well that means this wasn't introduced recently at least

[benthecarman]

Going to close this, #1039 should prevent it for now. Still have the underlying double init issue somewhere