Conversation
Change-Id: I4caa6d010f8f824aff1c38a7a73d08d47b400cce Signed-off-by: Thomas Kosiewski <tk@coder.com>
|
@codex review |
|
To use Codex here, create a Codex account and connect to github. |
|
@codex review |
|
To use Codex here, create a Codex account and connect to github. |
|
@codex review |
|
Codex Review: Didn't find any major issues. Swish! ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
/coder-agents-review |
There was a problem hiding this comment.
The debounce timer rework is well done. The nil-before-stop pattern in _cancel_debounce_timer() and the identity-based stale guard in the callback together correctly eliminate the race between cancellation and scheduled callback execution. The test suite covers the three hardest scenarios: re-debounce cancellation, stale callback rejection, and cleanup on disable. The plan was thorough and the implementation matches it.
One P2, three P3s, three nits.
The P2 is that the demotion timer callback (line 258, pre-existing) has the same class of stale-callback bug this PR fixes for the debounce timer. Seven reviewers independently flagged it. The PR modified the demotion timer's cleanup path in disable() and demonstrated the correct identity-guard pattern for debounce; the same pattern should be applied to the demotion callback. Details in the inline comment.
"What happens when they are not the same timer? Shall I show you?" (Hisoka)
lua/claudecode/selection.lua:258-264
P2 [DEREM-3] The demotion timer callback lacks the identity guard that the debounce callback has at line 152. A stale callback from a cancelled timer can close a replacement timer or corrupt latest_selection across a disable/enable cycle.
Sequence (Hisoka):
- User exits visual mode. Demotion timer A starts (50ms).
- Timer A fires.
vim.schedule_wrapqueues callback_A. - Before Neovim drains the queue, user types
viw<Esc>. Entering visual cancels A (lines 209-212). Exiting creates timer B at line 254. - callback_A runs.
M.state.demotion_timeris truthy (points to B). Lines 260-262 stop, close, and nil timer B. - Timer B's callback never fires. Demotion is permanently lost.
Separately (Meruem): after disable() nils and closes the timer, the queued callback still falls through to handle_selection_demotion(), which sets latest_selection. Since enable() does not reset latest_selection, this stale value persists into the next session.
The fix is the same pattern used for debounce: capture the timer instance in the closure and compare identity before acting.
local demotion_handle = vim.loop.new_timer()
M.state.demotion_timer = demotion_handle
demotion_handle:start(
M.state.visual_demotion_delay_ms,
0,
vim.schedule_wrap(function()
if M.state.demotion_timer ~= demotion_handle then
return
end
M.state.demotion_timer = nil
demotion_handle:stop()
demotion_handle:close()
M.handle_selection_demotion(current_buf)
end)
)(Hisoka P2, Meruem P2, Kite P3, Mafuuu P3, Takumi P3, Pariston P4, Chopper P4)
🤖
lua/claudecode/selection.lua:37
P3 [DEREM-7] The doc comment says "stops any active debounce timers" but this PR added demotion timer cleanup at lines 52-58. The doc now omits half the cleanup this function performs.
Suggestion: ---Clears autocommands, resets internal state, and cancels any pending debounce or demotion timers.
(Leorio P3)
🤖
🤖 This review was automatically generated with Coder Agents.
| assert(timer.stop, "Expected debounce timer to have :stop()") | ||
| assert(timer.close, "Expected debounce timer to have :close()") |
There was a problem hiding this comment.
P3 [DEREM-4] These asserts re-check timer.stop and timer.close on handles that already passed the same checks at creation (lines 141-143). They cannot fail for handles created through the normal code path.
More importantly, _cancel_debounce_timer() is called from disable() at line 50 before the demotion timer cleanup at lines 52-58. If these asserts throw (however unlikely), the demotion timer cleanup never runs and that handle leaks. Cleanup paths should not throw.
The codebase convention is to trust the libuv API contract: init.lua:95, server/tcp.lua:252, and the demotion timer at line 254 all call timer methods without asserting their existence first.
Consider removing lines 72-73 (and 141-143 in debounce_update). The useful asserts are line 137 (debounce_ms type check) and line 140 (nil-return guard from uv.new_timer()).
(Takumi P3, Hisoka P3, Zoro P3, Chopper Nit, Gon Nit, Kite Nit, Leorio Nit, Pariston Nit)
🤖
| M.state.debounce_timer = nil | ||
| M._cancel_debounce_timer() | ||
|
|
||
| if M.state.demotion_timer then |
There was a problem hiding this comment.
P3 [DEREM-1] The demotion timer cleanup (lines 52-58) is new code added by this PR but has no test coverage. The debounce timer cleanup in the same function is tested ("disable() should cancel an active debounce timer"), but no test sets up or checks demotion_timer during disable().
A test that enables tracking, assigns a mock timer to M.state.demotion_timer, calls disable(), and asserts stop/close/nil would cover this.
(Netero P3, Mafu-san P3)
🤖
| describe("debounce_update", function() | ||
| it("should cancel and close previous debounce timer when re-debouncing", function() | ||
| local update_calls = 0 | ||
| local old_update_selection = selection.update_selection |
There was a problem hiding this comment.
P3 [DEREM-6] Tests 1 and 2 in this block patch selection.update_selection at the top and restore at the bottom. If any assertion between them fails, the restore never runs. Test 2 then saves the leaked closure as old_update_selection, patches over it, and restores the wrong function when it finishes. The real update_selection is lost for the rest of the suite.
Consider a before_each/after_each pair on the debounce_update describe block, or use finally inside each test.
(Bisky P3)
🤖
| local logger = require("claudecode.logger") | ||
| local terminal = require("claudecode.terminal") | ||
|
|
||
| local uv = vim.uv or vim.loop |
There was a problem hiding this comment.
Nit [DEREM-5] local uv = vim.uv or vim.loop is introduced for forward compatibility but only used at line 139. The demotion timer at line 254 (vim.loop.new_timer()) and line 221 (vim.loop.now()) still call vim.loop directly. If/when Neovim removes vim.loop, the debounce timer survives and the demotion timer breaks. Either apply uv to all timer/loop calls in the file, or drop the alias and use vim.loop consistently.
(Meruem P3, Gon Nit, Hisoka Nit, Mafuuu Nit, Zoro Nit)
🤖
| return | ||
| end | ||
|
|
||
| -- Clear state before stopping/closing so cancellation is idempotent. |
There was a problem hiding this comment.
Nit [DEREM-8] Comment says "so cancellation is idempotent" but this is the fire path, not the cancel path. The nil here prevents a later _cancel_debounce_timer from double-stopping, but that's not what "cancellation is idempotent" communicates. Line 69 has the correct framing for the same pattern: "so any already-scheduled callback is a no-op."
(Gon Nit)
🤖
|
|
||
| return timer | ||
| end, | ||
| timer_stop = function(timer) |
There was a problem hiding this comment.
Nit [DEREM-10] The timer_stop mock is dead code. This PR removed all vim.loop.timer_stop() calls from production. No test exercises this mock. Could be removed to avoid implying the function is still used.
(Meruem Nit)
🤖
Fixes #172.
What changed
vim.uv/vim.loop) rather thanvim.defer_fn().:stop()'d +:close()'d when cancelled or fired.selection.disable()cancels any pending debounce/demotion timers.Why
The previous code mixed
vim.defer_fn()for creation withvim.loop.timer_stop()for cancellation and never closed the timer handle, which could lead to leaked handles and/or stale callbacks under rapid selection/cursor events.Testing
nix develop .#ci -c luacheck lua/claudecode/selection.lua tests/selection_test.lua --no-unused-args --no-max-line-lengthnix develop .#ci -c make test📋 Implementation Plan
Plan: Fix issue #172 (timer API mismatch / unsafe debounce timer cleanup)
Context / Why
Issue #172 reports that
lua/claudecode/selection.luacreates a debounce timer viavim.defer_fn()but cancels it viavim.loop.timer_stop(), and does notclose()the timer handle. This can lead to inconsistent timer handling and (more importantly) leaked or double-closed timer handles under rapid events, which may contribute to crashes on newer Neovim versions.Goal: Make selection debouncing use a single, consistent libuv timer API and ensure timers are always safely stopped + closed when cancelled or fired.
Evidence (verification)
lua/claudecode/selection.lua:49and:111callvim.loop.timer_stop(M.state.debounce_timer).lua/claudecode/selection.lua:114assignsM.state.debounce_timer = vim.defer_fn(...).vim.defer_fn()returns a userdata timer handle with:stop()and:close()methods.Plan
1) Implement a safe debounce timer using a libuv handle (no
vim.defer_fn)File:
lua/claudecode/selection.luavim.loop.new_timer()(orlocal uv = vim.uv or vim.loopthenuv.new_timer()), matching the rest of the module’s timer usage.stop()+close()the previous timer and setM.state.debounce_timer = nilbefore stopping/closing so any already-scheduled callback becomes a no-op.if M.state.debounce_timer ~= timer then return end) to avoid stale callbacks running after re-debounce.stop()+close()the timer and clear state before callingM.update_selection().Suggested structure (pseudocode):
M._cancel_debounce_timer()helper:M.state.debounce_timerthent = M.state.debounce_timerM.state.debounce_timer = nilt:stop(); t:close()M.debounce_update():M._cancel_debounce_timer()timer = uv.new_timer()M.state.debounce_timer = timertimer:start(M.state.debounce_ms, 0, vim.schedule_wrap(function() ... end))2) Fix
disable()cleanup to stop + close the debounce timerFile:
lua/claudecode/selection.luavim.loop.timer_stop(M.state.debounce_timer)call with the same safe cancellation helper from step 1.M.state.demotion_timerindisable()using the existing:stop(); :close(); nilpattern to prevent delayed callbacks firing after tracking is disabled.3) Update/extend unit tests to cover the debounce contract
Files:
tests/selection_test.lua(standalone vim mock)tests/mocks/vim.lua(shared mock) if neededAdd tests that validate:
selection.debounce_update()twice rapidly cancels/cleans the previous timer (assertstop()andclose()called once on the old handle).update_selection().selection.disable()cancels the active debounce timer without error.To make this deterministic in unit tests, adjust the timer mock to:
callbackfromtimer:start(...)without auto-executing, and expose atimer:fire()helper for tests.4) Regression check
make check(syntax + luacheck).make test(busted).Notes / Rationale
Why avoid “just change timer_stop to :stop()/:close()” while keeping vim.defer_fn?
vim.defer_fn()typically wraps a libuv timer and closes it internally when it fires. If we alsoclose()the handle on cancel, there is a race where the timer fires, schedules its wrapper callback, then we cancel+close, and later the wrapper tries to close again. Implementing the debounce timer directly withuv.new_timer()gives us full control and enables a simple “stale timer” guard.Generated with
mux• Model: openai:gpt-5.2 • Thinking: xhigh