fix: avoid race condition in async parallel parse/parseInline with hooks

[ordinary9843]

Closes #3836.

When parse() and parseInline() are called concurrently with hooks present, both calls write to opt.hooks.block — the same shared hooks instance. The second call overwrites block before the first call reaches provideLexer() or provideParser(), so both end up using the same lexer/parser (either both block or both inline).

The fix passes blockType directly as an argument to provideLexer(block) and provideParser(block) so the shared hooks instance is never mutated during parsing. The block property is kept on _Hooks for backwards compatibility with custom hook implementations that override these methods and read this.block.

All 1900 existing tests pass.

[vercel]

@ordinary9843 is attempting to deploy a commit to the MarkedJS Team on Vercel.

A member of the Team first needs to authorize it.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a race condition in the marked library that occurs when parse() and parseInline() are called concurrently with hooks enabled. The fix ensures that the correct lexer and parser are used in concurrent scenarios by passing the blockType directly to the provideLexer() and provideParser() methods. This prevents shared hooks from being overwritten and causing incorrect parsing. The changes also maintain backwards compatibility with existing custom hook implementations.

Highlights

• Race Condition Fix: Addresses a race condition where concurrent calls to parse() and parseInline() could lead to incorrect lexer/parser selection due to shared hooks being overwritten.
• Block Type Handling: Passes blockType directly to provideLexer() and provideParser() to ensure the correct lexer and parser are used, regardless of concurrent calls.
• Backwards Compatibility: Maintains the block property on _Hooks for backwards compatibility with custom hook implementations.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request effectively addresses a race condition that occurs during concurrent parsing with hooks by passing blockType as an argument to provideLexer and provideParser instead of mutating a shared hooks instance. The changes in src/Hooks.ts and src/Instance.ts are logical and correctly implement this fix.

However, I've identified a potential breaking change for custom hooks that rely on this.block, which seems to contradict the backward compatibility claim in the pull request description. I've left a detailed comment on this matter in src/Instance.ts. Addressing this point will ensure the change is either correctly documented as a breaking change or adjusted to maintain compatibility as intended.

[ordinary9843]

You're right, thanks for pointing that out. Restored the assignment so existing custom hooks that read this.block won't break.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
marked-website	Ready	Preview, Comment	Mar 29, 2026 3:02am

[UziTech]

This looks like a good fix. Can you write some tests?

[ordinary9843]

Added tests covering:

• concurrent parse() + parseInline() with async hooks produce correct block/inline output
• multiple concurrent calls (parse, parseInline, parse) resolve independently
• provideLexer and provideParser each receive block=true from parse() and block=false from parseInline()
• correct block values forwarded under concurrent async conditions
• this.block backwards compatibility preserved for both hooks in both parse modes

[UziTech]

Thanks 💯