Chained fallbacks override not working
If I have a mount 1a falling back (and overriding) 2a, falling back (and overriding) 3, if 1a fails, 2a fails, 1a starts again: listeners are stuck on 3.
This happens on devel-phschafft (on devel, it "works", but we have #2491 (closed) biting us, and counters get wrong).
In the same config scenario as there:
<mount>
<mount-name>/first-level-a</mount-name>
<password>nohackplz</password>
<fallback-mount>/second-level-a</fallback-mount>
<fallback-override>own</fallback-override>
<public>0</public>
<hidden>0</hidden>
</mount>
<mount>
<mount-name>/second-level-a</mount-name>
<password>nohackplz</password>
<fallback-mount>/third-level-last-resort</fallback-mount>
<fallback-override>own</fallback-override>
<public>0</public>
<hidden>0</hidden>
</mount>
<mount>
<mount-name>/third-level-last-resort</mount-name>
<password>nohackplz</password>
<public>0</public>
<hidden>0</hidden>
</mount>
Scenario: All mount have a working sources. One listener is connected to /first-level-a. I stop first-level-a. Listener falls back to second-level-a. I stop second-level-a. Listener falls back to third-level-last-resort. I restart first-level-a. Listener is stuck on third-level-last-resort. I have to restart second-level-a for it to override, and then restart first-level-a to get listeners to be moved there.
Here is the debug log:
[2024-04-21 18:03:30] DBUG client/client_create Client 0x7b5f0800b6f0 created on connection 0x7b5f0800b460 (connection ID: 65, sock=13, socket real: 0x5c90222f2cc0 (-), socket effective: 0x5c90222f2cc0 (-); global: 5 of 500)
[2024-04-21 18:03:30] DBUG fastevent/fastevent_emit event: type=6, flags=1, datatype=2, ...
[2024-04-21 18:03:30] DBUG fserve/fserv_thread_function fserve handler exit
[2024-04-21 18:03:30] DBUG source/source_init Source creation complete
[2024-04-21 18:03:30] DBUG fastevent/fastevent_emit event: type=0, flags=0, datatype=1, ...
[2024-04-21 18:03:30] DBUG source/source_init source=0x7b5f0000a150{.mount="/first-level-a", .fallback_override=2, .fallback_mount="/second-level-a", ...}
[2024-04-21 18:03:30] DBUG source/source_init source=0x7b5f0000a150{.mount="/first-level-a", .fallback_override=2, ...}, fallback_source=0x7b5f00003560{.mount="/third-level-last-resort", ...}
[2024-04-21 18:03:30] DBUG navigation/navigation_history_navigate_to Called with history=0x5c9022356748, identifier=0x7b5f000024f0 ("/first-level-a"), direction=up
[2024-04-21 18:03:30] WARN source/source_move_clients__single Can not change history: navigation of client=0x5c90223566c0{.con->id=8, ...} from source=0x7b5f00003560{.mount="/third-level-last-resort", ...} to dest=0x7b5f0000a150{.mount="/first-level-a", ...} with direction up failed
[2024-04-21 18:03:30] INFO source/source_move_clients passing 0 listeners to "/first-level-a"
[2024-04-21 18:03:30] DBUG client/client_body_read Reading from body (client=0x5c902238df30)
As @phschafft was telling on IRC, the reason behind this is because when navigation_history_navigate_to is called, it checks history size, and checks if the aimed destination is the previous entry in the history (history->history[history->fill - 2]
). Though in that case, it's not, because it's one step further (I may not understand the logic correctly here, but in the end, it fails…).
I'm not sure how to fix this, it's not easy not to make it go awfully wrong… Something along the lines of: let's maybe check if that destination indeed is in the history, higher than the current position, and pop all entries until we reach it?