Stefan HallerandClaude Opus 4.7 e53c72be52 Make ViewBufferManager.NewTask respect call order ...

NewTask was incrementing newTaskID and reading taskID inside the
spawned goroutine, so for two NewTask calls in quick succession the
assignment was determined by goroutine scheduling order rather than
call order. When the goroutines reordered, the first NewTask call
could end up with the higher taskID and "win" the staleness check,
superseding the second call's task even though the caller intended
the second to be the latest.

Worse, the staleness check ran after onNewKey, so a goroutine destined
to bail as stale would still reset the view buffer first, potentially
wiping the winning task's already-written output.

Take newTaskID++ synchronously in NewTask so taskIDs follow call order,
and move the first staleness check ahead of onNewKey so a stale task
doesn't side-effect the view before exiting.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-07-02 17:24:48 +02:00

..

async_handler_test.go

Copy gocui files into lazygit repo under pkg/gocui

2026-04-30 14:29:08 +02:00

async_handler.go

Copy gocui files into lazygit repo under pkg/gocui

2026-04-30 14:29:08 +02:00

tasks_test.go

Copy gocui files into lazygit repo under pkg/gocui

2026-04-30 14:29:08 +02:00

tasks.go

Make ViewBufferManager.NewTask respect call order

2026-07-02 17:24:48 +02:00