Cancelled streaming requests leave waiting animation running, preventing Kobo suspend and draining battery

[fernandeslouro]

Cancelling an Assistant streaming request before response text arrives leaves the waiting animation running after the dialog closes. On my Kobo Clara B&W, this prevents actual suspend and drains the battery while the sleep image remains visible. A small local patch fixes the reproduced failure.

Hardware and software

• Kobo Clara B&W, model 395; KOReader device ID Kobo_spaBW.
• Device tree / CPU hardware string: MediaTek MT8110 TPV board.
• Device-tree compatibles: mediatek,mt8110, mediatek,mt8512.
• ARMv7 userspace; CPU implementer 0x41, part 0xd03 (Cortex-A53).
• Kobo firmware 4.45.23792; Linux 4.9.77, build 821e4df-20250506T120645-B0506121817.
• KOReader v2026.07.2; AI Assistant v1.19.
• 1072 x 1448 display, 300 dpi, MediaTek HWTCON driver.

Confirmed plugin defect

UIManager:scheduleIn() returns nil. showStremDialog() stores that return value in animation_task, then only calls unschedule() when that variable is truthy. The waiting animation therefore cannot be cancelled through that code.

If a streaming dialog closes before receiving content, first_content_received stays false and updateAnimation() keeps re-enqueuing itself every 0.4 seconds. Cleanup is also missing after processStream() returns an error, empty response or tool call, or raises an exception.

StreamText:initTextBox() calls UIManager:setDirty() with a refresh callback. KOReader queues and executes these callbacks even when the associated widget is absent from the window stack, so the orphan animation can keep requesting display refreshes.

Observed battery-drain incident

The device last successfully returned from suspend at 2026-10-11 11:56:52 UTC. At 12:01:05 the log records User interrupted the stream processing. At 12:01:15 Wi-Fi was disabled; the suspend attempt at 12:01:31 failed:

Cannot write `mem` to file `/sys/power/state`: Operation not permitted
Kobo suspend: the kernel refused to enter suspend!

All subsequent recorded suspend attempts failed through 2026-10-12 00:53:02. The device was rebooted by the time it was inspected at 21:54 UTC, so the kernel diagnostics from the failing boot are unavailable. The battery was 8% and charging at inspection. Auto-suspend is 900 seconds; auto-shutdown is 259200 seconds (three days). KOReader stops retrying after 20 failures and waits for shutdown, allowing substantial drain while a sleep screen remains visible.

The unplugged hardware reproduction also triggered the suspend failure. After interrupted requests at 2026-10-12 22:06:15 and 22:06:24 UTC, all six suspend attempts failed. Kernel suspend statistics identify 14000000.hwtcon, errno -1, step suspend. The saved kernel log reports:

[HWTCON ERR]hwtcon_fb_suspend EPD power off timer is pending ! @hwtcon_fb_suspend,2254
PM: Device 14000000.hwtcon failed to suspend: error -1

This matches the display-refresh explanation and the HWTCON failure discussed in koreader/koreader#12787. After installing the patch and restarting KOReader (without rebooting the device), the user repeated the interrupted-stream steps: interruption at 22:10:44 UTC, successful suspend at 22:11:20, and resume at 22:12:49. The kernel reports 89.121 seconds suspended; counters changed from success 1 / fail 6 to success 2 / fail 6, with no new failures. This provides a successful before-and-after hardware reproduction.

Reproduction and proposed fix

Start a streaming request and close it before the first response text. Confirm that no waiting-animation callback remains queued after close. Also exercise an API error, empty response, thrown exception, and tool-only response before text.

The patch keeps the scheduled function reference rather than the return value of scheduleIn(), cancels it before interrupting the stream, and cancels it when stream processing returns on every exit path.

Validation

• A deterministic scheduler test invokes the actual Querier:showStremDialog() method. Original code fails all five cleanup scenarios; patched code passes all five.
• LuaJIT syntax check passes; git diff --check passes.
• Full plugin suite run using the Kobo's actual KOReader runtime: 597 passed, 3 failed, with byte-identical output before and after the patch. The three existing failures are in test_markdown_css.
• Unplugged baseline after reboot, with original plugin still installed: successful suspend at 2026-10-12 22:02:59 UTC, resume at 22:04:16; kernel reports 76.686 seconds suspended, success 1 / fail 0. Ordinary sleep currently works.
• Original-code hardware reproduction: cancellation followed by sleep failed six times; HWTCON EPD power-off timer was pending. Diagnostic capture saved at 22:07 UTC before Wi-Fi was re-enabled.
• The patch was installed on the Kobo, passed syntax validation with its bundled LuaJIT, and matched the uploaded file checksum. Original source backed up as assistant_querier.lua.before-suspend-fix.
• After restarting KOReader with the patch, the repeated cancellation-and-sleep test succeeded for 89.121 seconds with no additional suspend failures.
• Longer-term battery retention has not yet been measured; the demonstrated suspend failure is fixed in this reproduction.

Tested patch

diff --git a/assistant_querier.lua b/assistant_querier.lua
index 6a2f5de..347c17e 100644
--- a/assistant_querier.lua
+++ b/assistant_querier.lua
@@ -759,11 +759,11 @@ function Querier:showStremDialog(res, request_title, request_identity)
     local animation_task = nil -- Will be set during animation setup
 
     local function _closeStreamDialog()
-        if self.interrupt_stream then self.interrupt_stream() end
         if animation_task then
             UIManager:unschedule(animation_task)
             animation_task = nil
         end
+        if self.interrupt_stream then self.interrupt_stream() end
         UIManager:close(streamDialog)
     end
 
@@ -848,10 +848,11 @@ function Querier:showStremDialog(res, request_title, request_identity)
     local function updateAnimation()
         if not first_content_received then
             streamDialog._input_widget:setText(animation:getNextFrame(), true)
-            animation_task = UIManager:scheduleIn(0.4, updateAnimation)
+            UIManager:scheduleIn(0.4, updateAnimation)
         end
     end
-    animation_task = UIManager:scheduleIn(0.4, updateAnimation)
+    animation_task = updateAnimation
+    UIManager:scheduleIn(0.4, animation_task)
 
     local pending_delta = strbuf.new()  -- delta since the last UI flush
     local flush_scheduled = false
@@ -890,6 +891,10 @@ function Querier:showStremDialog(res, request_title, request_identity)
             end
         end
     end)
+    if animation_task then
+        UIManager:unschedule(animation_task)
+        animation_task = nil
+    end
     local err
     if flush_scheduled then
         UIManager:unschedule(flush_to_ui)

Automation disclosure

The investigation, patch preparation, and report were automated with Codex using GPT-6.1 Sol. I performed the physical cancellation, restart, and sleep tests on the Kobo. This report includes a tested patch; no pull request has been opened yet.

[boypt]

Thanks for the detailed report and the tested patch. The fix is merged as 7d0f22b ("fix: stop waiting animation after cancelled or failed streams"). It keeps the animation function reference so it can be unscheduled, cancels it on close before interrupting the stream, and cancels it after processStream returns on every exit path. I added a regression test (test/test_stream_animation_cleanup.lua). The full suite passes. Closing this as resolved; please reopen if the suspend issue persists on your device.