Non-root number separator validation not applied to non-blocking (async) parser (follow-up to #1557)

Open
  • Is something wrong?
#1,640 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@seonwooj0810 is already working on this.

Since Aug 8, 2026.

  • #1648 by @seonwooj0810 — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
java
Domain
backend

Research direction

Start in NonBlockingJsonParserBase and compare its number-completion sites with the equivalent checks in ReaderBasedJsonParser, UTF8StreamJsonParser, and UTF8DataInputJsonParser. Exercise the listed malformed inputs across chunk boundaries, and consider the work done when async parsing reports the error at the offending character while deferring decisions at NEED_MORE_INPUT boundaries.

Written by the indexing model from the issue text.

Description

Follow-up to #1557 / #1615, as discussed in https://github.com/FasterXML/jackson-core/pull/1615#issuecomment (with @cowtowncoder agreeing async warrants a separate change).

Background

#1615 generalized the root-only _verifyRootSpace into _verifyNumberSeparator and now eagerly validates the separator after non-root number values, but only in the three blocking parsers (ReaderBasedJsonParser, UTF8StreamJsonParser, UTF8DataInputJsonParser).

The non-blocking / async parser path (NonBlockingJsonParserBase and its subclasses NonBlockingJsonParser / NonBlockingByteArrayJsonParser) was intentionally left out of that PR and still fails lazily — the malformed content is only detected when the next token is read, one token too late.

Repro

The same inputs from #1557 that are now caught eagerly by the blocking parsers still slip through on the async path:

[ 123true ]   // -> reports number token 123, fails only on next token
[ 100k ]      // -> 100
[ 100/ ]      // -> 100
[ 1.5x ]      // -> 1.5
[ 1.5false ]  // -> 1.5
Scope

Apply the equivalent trailing-separator check at the number-completion sites in the non-blocking parser so async parsing reports the error at the offending character, matching the blocking parsers' behavior and location. Async introduces NEED_MORE_INPUT boundaries at end-of-chunk, so the check has to tolerate a not-yet-available trailing byte (defer the decision to the next feed rather than reject), which is why this is a separate change from #1615.

Happy to pick this up.

Dominant language
Java
Stars
2.4k
Forks
952
Avg merge
3d 6h
Merged PRs (30d)
32

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from FasterXML/jackson-core

All issues in FasterXML/jackson-core

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.