Found while fixing #236 and deliberately not folded in.
What happens
Activate a game row. The resolver picks a release, the download comes back empty (or fails), the app puts up a toast saying the source returned no data, and the toast fades a few seconds later. No game: line is written because openGamePath was never reached. A user looking at the shelf a moment later sees exactly what they saw before the press.
That is precisely how #236 was filed: as "the shelf's Play never reaches openGame", with RetroPark and NES suspected, when the real event was a failed download whose only trace had already faded.
Why it matters
Every remote-open failure funnels through this one surface (reportOpenFailure after the #207-#218 audiobook work made that the single path, which is good). A single fading toast is the right shape for "saved" or "added to favourites"; it is the wrong shape for "the thing you asked for did not happen and here is why". Music and audiobooks got a persistent failure state in the player for the same reason (#217, #218); games have nothing equivalent because the player never opened.
Shape of a fix
A failure that ends a press without opening anything should leave something that stays until the user acts: the item's detail page (themed and classic — both, per the two-builders rule) showing the failure text and a retry / choose-another-source verb, or at minimum a toast that does not auto-dismiss on this class of error. The message text already exists; what is missing is persistence and a place to act from. probe_uitest can pin it: a 0-byte fetch must leave the failure visible in state after the toast's normal lifetime.
Related: the 0-byte body itself is a server-side defect tracked in the plugin repo.
Found while fixing #236 and deliberately not folded in.
What happens
Activate a game row. The resolver picks a release, the download comes back empty (or fails), the app puts up a toast saying the source returned no data, and the toast fades a few seconds later. No
game:line is written becauseopenGamePathwas never reached. A user looking at the shelf a moment later sees exactly what they saw before the press.That is precisely how #236 was filed: as "the shelf's Play never reaches openGame", with RetroPark and NES suspected, when the real event was a failed download whose only trace had already faded.
Why it matters
Every remote-open failure funnels through this one surface (
reportOpenFailureafter the #207-#218 audiobook work made that the single path, which is good). A single fading toast is the right shape for "saved" or "added to favourites"; it is the wrong shape for "the thing you asked for did not happen and here is why". Music and audiobooks got a persistent failure state in the player for the same reason (#217, #218); games have nothing equivalent because the player never opened.Shape of a fix
A failure that ends a press without opening anything should leave something that stays until the user acts: the item's detail page (themed and classic — both, per the two-builders rule) showing the failure text and a retry / choose-another-source verb, or at minimum a toast that does not auto-dismiss on this class of error. The message text already exists; what is missing is persistence and a place to act from.
probe_uitestcan pin it: a 0-byte fetch must leave the failure visible instateafter the toast's normal lifetime.Related: the 0-byte body itself is a server-side defect tracked in the plugin repo.