fix(io): make logger mode concurrency-safe and fix writer mode restore - #112
Merged
Conversation
Std{Out,Err}Writer temporarily flip the shared logger's mode on every write.
When a command's stdout and stderr are copied concurrently (os/exec uses one
goroutine per stream), those writers read (LogMode) and write (SetMode) the
StandardLogger.mode field with no synchronization — a data race under -race.
- Guard StandardLogger.mode with a RWMutex (modeMu). The underlying charm log
handlers are already internally synchronized, so only this field needed it.
- Serialize the writers' flip/render/restore sequence with a second mutex
(writeMu), exposed to the writers in-package, so concurrent writers cannot
interleave and render each other's output in the wrong mode.
- Fix StdOutWriter, which reassigned its saved mode after flipping and so never
restored the logger's original mode (StdErrWriter was already correct). Both
writers now share one flip/restore path guarded by a `flipped` flag.
Adds a regression test that drives both writers concurrently with a mode
different from the logger's; it reports DATA RACE under -race without the fix,
and also asserts the logger's mode is restored afterward.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
jahvon
added a commit
to flowexec/flow
that referenced
this pull request
Jul 26, 2026
tuikit v0.4.1 makes StandardLogger's mode concurrency-safe and fixes the
Std{Out,Err}Writer restore path (flowexec/tuikit#112). That resolves the data
race between a command's concurrently-copied stdout and stderr streams at the
source, so no client-side workaround is needed here.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
jahvon
added a commit
to flowexec/flow
that referenced
this pull request
Jul 26, 2026
## Summary Bumps tuikit `v0.4.0` → `v0.4.1`, which fixes the logger data race at the source (flowexec/tuikit#112) instead of working around it in flow. The race was between a command's stdout and stderr streams (copied by os/exec in separate goroutines) both flipping `StandardLogger`'s shared `mode` field. tuikit v0.4.1: - guards the `mode` field with a mutex, - serializes the writers' flip/render/restore sequence, and - fixes `StdOutWriter` never restoring the mode after a flip. Since the fix lives in the dependency, no client-side change is needed here beyond the version bump — this PR previously carried a `syncWriter` workaround, now removed in favor of the upstream fix.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes a data race on
StandardLogger.mode(reported downstream bygo test -raceduring concurrent command execution), plus a latent bug whereStdOutWriternever restored the logger's mode.StdOutWriter/StdErrWritertemporarily flip the shared logger's mode on everyWritesoInfo/Noticerender in the desired format. When a command's stdout and stderr are copied concurrently (os/exec uses one goroutine per stream), those writers callSetMode(write) andLogMode(read) on the sharedmodefield with no synchronization:Changes
modeis now guarded by async.RWMutex(modeMu).SetModewrite-locks;LogModeand all internal reads go through acurrentMode()read-locked accessor. The underlying charmlog.Loggerhandlers are already internally synchronized, so only this field needed protection.writeMu), exposed to the writers in-package, so two concurrent writers can't interleave and render each other's output in the wrong mode.StdOutWriter's restore: it reassigned its savedcurModeto the new mode after flipping, so the restore-defer condition was always false and the logger was left permanently in the flipped mode (StdErrWriterdidn't have this bug). Both writers now use a single, correct flip/restore path gated on aflippedflag.Testing
WARNING: DATA RACEunder-racewithout the fix and passes with it — verified both ways — and also asserts the logger's mode is restored afterward.go test -race ./...;golangci-lintclean.Downstream note
flow currently carries a client-side workaround (serializing these writers itself). Once this is released and flow bumps tuikit, that workaround can be removed.
🤖 Generated with Claude Code