Fimeg/souveraine
Watch
1
0
Fork
You've already forked souveraine
 0
Code Releases Activity

shell: wait longer for shell_ready than sessiond takes to answer it

Browse source 
`shell_ready` blocks in the daemon for up to 5s waiting for its
lock-session thread to drop its Wayland connection, because the
compositor refuses a second locker while the first is alive
(server.rs `wait_timeout_while`). The shell's timer was 3s, so it gave
up on a handshake sessiond was still answering, assumed locked, and
asked for a lock that had not been released — straight into TASK-48's
"Tried to show lockscreen surfaces without active lock".

Under Hyprland the release usually lands in milliseconds and the race is
won. Measured against viewtop on blueline today it loses every time: the
shell crash-looped every 11 seconds and the session never came up.
Same latent bug, a compositor that exposes it.

7s, so the daemon's own deadline expires first. Its answer for that case
is a refusal (`lock session did not release in time`), and hearing a real
refusal beats inventing a verdict — "assuming locked" is the shell
holding state the authority owns.

The 5s retry timer only arms after this one fires, so nothing overlaps.
This commit is contained in:
Fimeg 2026-08-02 11:15:44 -04:00
commit 870d88210b
1 changed files with 20 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

21
surfaces/quickshell/services/SessiondBridge.qml
View file

@ -107,7 +107,26 @@ Singleton {
Timer {
id: readyTimeout
interval: 3000
// Longer than sessiond's own deadline, and that ordering is the whole
// point. `shell_ready` blocks in the daemon for up to 5 s waiting for
// its lock-session thread to drop its Wayland connection, because the
// compositor refuses a second locker while the first is alive
// (server.rs, `wait_timeout_while`). At 3 s this timer fired *first*,
// so the shell gave up on a handshake the daemon was still answering,
// assumed locked, and asked for a lock sessiond had not released yet —
// straight into TASK-48's `Tried to show lockscreen surfaces without
// active lock`.
//
// Under Hyprland that race is usually won: the release lands in
// milliseconds. Measured against viewtop on blueline 2026-08-02 it
// loses every time — the shell crash-looped every 11 s and never came
// up. Same latent bug, a compositor that exposes it.
//
// The daemon has an answer for this case and it is a refusal
// (`lock session did not release in time`). Waiting for a real refusal
// beats inventing a verdict: `assuming locked` is the shell holding
// state the authority owns, which is the failure doctrine §4 is about.
interval: 7000
repeat: false
onTriggered: {
if (root.pendingReady) {