Last of the defects found in the investigation behind #210, #211 and #212.
Filing as an issue rather than a PR because the right recovery behavior is
a design decision worth discussing first.
When an SnItem's initial GetAll call fails, get_all_properties_callback()
frees the error and returns. Nothing ever revisits the item:
- the status icon keeps the placeholder sortable name it was constructed
with, and never gets an icon, tooltip or menu
- a client in this state typically emits no NewIcon/NewStatus signals
either (if its object were reachable enough to signal, GetAll would have
worked), so no future event triggers another property fetch
- the item stays registered and published, so the panel renders a
broken-image glyph for the lifetime of the application
This is what #208 and #209 report from the field. Electron 43.3.0 through
43.4.0 shipped an SNI implementation that did not answer the watcher's
property fetches (electron/electron#52952), so GetAll failed once and the
icon was dead for the whole session, every session, which is also the
mechanism behind signalapp/Signal-Desktop#7995 "persists across reboots".
One correction to #209's analysis: the watcher never issues per-property
Get calls, only GetAll through its property proxy, and the missing
/dev/shm/xapp-tmp-*.png in that report shows the watcher's own GetAll
failed even though manual queries addressed differently succeeded. The
per-property Get behavior is a symptom of the same broken client, not the
path the watcher takes.
Electron fixed their regression in 43.4.1, but the one-shot fetch also
loses two ordinary races against perfectly healthy clients:
- a client may register before its /StatusNotifierItem object is fully
exported, so the watcher's GetAll arrives too early and fails, even
though the client is fine a moment later
- the GetAll uses a 5 second timeout, and the time this matters most is
session startup, when every autostarted tray app is initializing at
once; a busy client can miss that deadline exactly once and currently
pays for it with a dead icon for the rest of the session
Suggested behavior, combining recovery for the transient cases with
graceful degradation for the permanent ones:
- Retry the failed fetch a few times with a short backoff before giving
up. This recovers both races above.
- Keep the icon hidden until a property fetch has succeeded, so a client
that never answers (like the broken Electron versions) degrades to an
invisible entry instead of a permanent broken-image glyph in the panel.
A third option would be to drop the item entirely on repeated failure,
but that seems worse: a client that recovers later (emits a signal,
answers a subsequent fetch) would be gone for good, since nothing
re-registers it.
Happy to put together a PR along these lines if this direction sounds
right.
Last of the defects found in the investigation behind #210, #211 and #212.
Filing as an issue rather than a PR because the right recovery behavior is
a design decision worth discussing first.
When an SnItem's initial GetAll call fails, get_all_properties_callback()
frees the error and returns. Nothing ever revisits the item:
with, and never gets an icon, tooltip or menu
either (if its object were reachable enough to signal, GetAll would have
worked), so no future event triggers another property fetch
broken-image glyph for the lifetime of the application
This is what #208 and #209 report from the field. Electron 43.3.0 through
43.4.0 shipped an SNI implementation that did not answer the watcher's
property fetches (electron/electron#52952), so GetAll failed once and the
icon was dead for the whole session, every session, which is also the
mechanism behind signalapp/Signal-Desktop#7995 "persists across reboots".
One correction to #209's analysis: the watcher never issues per-property
Get calls, only GetAll through its property proxy, and the missing
/dev/shm/xapp-tmp-*.png in that report shows the watcher's own GetAll
failed even though manual queries addressed differently succeeded. The
per-property Get behavior is a symptom of the same broken client, not the
path the watcher takes.
Electron fixed their regression in 43.4.1, but the one-shot fetch also
loses two ordinary races against perfectly healthy clients:
exported, so the watcher's GetAll arrives too early and fails, even
though the client is fine a moment later
session startup, when every autostarted tray app is initializing at
once; a busy client can miss that deadline exactly once and currently
pays for it with a dead icon for the rest of the session
Suggested behavior, combining recovery for the transient cases with
graceful degradation for the permanent ones:
up. This recovers both races above.
that never answers (like the broken Electron versions) degrades to an
invisible entry instead of a permanent broken-image glyph in the panel.
A third option would be to drop the item entirely on repeated failure,
but that seems worse: a client that recovers later (emits a signal,
answers a subsequent fetch) would be gone for good, since nothing
re-registers it.
Happy to put together a PR along these lines if this direction sounds
right.