Stefan HallerandClaude Opus 5 01600042cd Guard taskKey with the mutex that already guards the task ID ...

taskKey is written on the goroutine NewTask spawns, under taskIDMutex, but
GetTaskKey read it without the lock — and the string renders in
tasks_adapter.go call that from the UI thread while a previous task's
goroutine may be writing. A Go string is a two-word value, so a torn read
can pair one string's pointer with another's length and index out of
bounds, not merely return the wrong key.

Take the lock in GetTaskKey, and read the field directly at the one call
site that already holds it.

No test: the failure needs two goroutines to interleave inside a
two-word assignment, which nothing can schedule deterministically.

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

2026-08-15 15:30:27 +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

Let OnUIThreadAndWait's error be about the wait, not about f

2026-08-12 11:04:53 +02:00

tasks.go

Guard taskKey with the mutex that already guards the task ID

2026-08-15 15:30:27 +02:00