Skip to content

🤖 fix: CodeBlock highlight cache should adopt writer ownership on cache-hit remounts #4677

Description

@ThomasK33

Follow-up from #4676 (Codex round 4, deferred under the blocker-only rule after round 3).

CodeBlock's highlight cache (src/browser/features/Messages/MarkdownComponents.tsx) keeps Shiki results so a block remounted by a Streamdown static↔streaming mode flip paints highlighted. On a cache hit (the useState initializer or the effect's early return), the remounted instance does not record cacheKey in lastWrittenCacheKeyRef or add itself as a writer. If that block then grows, its next write passes replacesKey === null, so the pre-remount entry stays until the LRU evicts it. When the cache is at its 32-entry bound, that stale entry can evict a live fence of the same reply, and the fence briefly re-highlights at the completion remount. That brief re-highlight is what main does at every flip today.

Fix sketch: on a cache hit, add the instance's writer symbol to the entry and set lastWrittenCacheKeyRef.current = cacheKey. Extend TypewriterMarkdown.backfill.test.tsx with a case that fills the cache to the bound.

Trigger: the next change to CodeBlock highlighting or TypewriterMarkdown.


Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions