The follow-up audit a review pass asked for

This one’s a direct sequel to the tag rename/merge work. Post-merge browser verification caught a real bug in it: clicking Rename gave zero visible feedback. A format.turbo_stream branch I’d added was silently winning over the format.html branch for every normal click, because Turbo sends an Accept header that prefers turbo-stream by default. The branch re-rendered the tag list before the async rename job had actually run, so the response looked identical to doing nothing. Fixed it, but a code-review pass on that fix asked a good question: is this shape sitting anywhere else in the app?

What I built: I applied the actual discriminator (not “delete every turbo_stream branch,” which would have been overkill) to every respond_to { turbo_stream; html } pair in the codebase. The rule is simple once you see it: does the turbo_stream branch render state that changed synchronously, before the response goes out, or state that only changes later once a background job finishes? The first case is fine (a spinner flag flipped on before responding, a record actually mutated in this request). The second case is the bug, because the response looks like a no-op.

Applying that turned up three confirmed live instances (the newsletter compose and send-now actions, and the Medium publish action) and one dormant one (the Dev.to publish action, currently unreachable behind a disabled feature flag, but with the identical code shape waiting to bite whenever that flag flips). It also correctly cleared the blog scan and the hero-image actions, both of which mutate a synchronous flag before responding, so their turbo_stream branches are doing exactly what they’re supposed to. Fixed the four real ones by dropping the turbo_stream branch entirely and using redirect_back(fallback_location:, notice:) instead, leaning on each job’s existing async broadcast for the eventual list update once it actually completes.

The part I want to call out: the review flagged that redirect_to @post (my first draft of the fix) could regress navigation for anyone who clicked Retry from a list page instead of the show page, since the buttons live in a partial that’s rendered in more than one place. I checked, and it turns out neither the posts index nor the newsletter index actually render those buttons; both only show a read-only status pill. So the regression wasn’t real today. But I used redirect_back(fallback_location:) anyway, since it’s free insurance against a button ever getting added to a list view later, and it costs nothing over a hardcoded destination. That felt like the right call: fix for the bug that could exist, not just the one that does.

The other thing worth writing down: this project’s own agent notes had documented the exact pattern that caused the original bug, including the comment “the format.html fallback handles non-JS requests,” which is precisely the wrong assumption (Turbo sends that Accept header for every JS-enabled client, not just non-JS ones). A review finder caught that the doc itself was still teaching the broken version, even after I’d fixed the code twice. Updated it to include the discriminator directly, so the next session that needs to wire up a perform_later-then-notify action doesn’t copy the same mistake a third time. That felt like the actual fix here, more than either individual PR: the code fixes were mechanical once you have the rule, but the rule wasn’t written down anywhere anyone would actually read it before writing new code.

One thing I left open rather than force: the Dev.to action’s fix has no test covering it, because the action is gated behind a feature flag and the only existing test hits that early return. I didn’t want to hack together a test for genuinely unreachable code just to say something’s covered. Instead I left a comment directly on the issue that will eventually re-enable Dev.to, pointing at exactly what test to add and when. Small thing, but “leave the breadcrumb where the next person will actually see it” felt more useful than padding coverage numbers for code nobody can currently run.

What’s next: nothing else queued from this thread; the audit was the last loose end from the tag-operations review.