Proposal: Option to enforce StreamReadConstraints string limits during serialization

[auloin]

Hi there,

I'm a maintainer of JobRunr, an open-source library for background job processing. JobRunr provides a Jackson integration for job serialization, which is used by most of our users.

I'd like to propose an improvement to address the asymmetry between string serialization and deserialization constraints in Jackson.

The issue

We've received multiple bug reports from users encountering exceptions such as:

com.fasterxml.jackson.databind.JsonMappingException: String value length (20054016) exceeds the maximum allowed

See, for example, jobrunr/jobrunr#1403 and jobrunr/jobrunr#1515.

As a library, there is little we can do to prevent this from happening. Users may introduce large strings anywhere in a job's arguments or exception messages and stack traces. More importantly, the serialization library, in this case, Jackson, has complete control over how job arguments are serialized.

The main problem is that Jackson allows a string to be serialized even when its length exceeds the configured maximum for deserialization, only to reject that same string when it is subsequently read back.

This asymmetry is difficult for applications to reason about, particularly when they rely on Jackson for both serialization and deserialization. It can result in data being successfully serialized but then rejected during deserialization with the same Jackson configuration.

Suggested improvement

Our current workaround would be to implement a custom StringSerializer that rejects strings exceeding the configured StreamReadConstraints.getMaxStringLength() limit. However, this duplicates logic that Jackson could provide out of the box, and any application facing the same issue would need to implement a similar workaround.

I'd like to propose adding an option to enforce read constraints during serialization as well. For example:

JsonMapper mapper = JsonMapper.builder()
    .enable(StreamWriteFeature.ENFORCE_READ_CONSTRAINTS)
    .build();

When enabled, this feature would ensure that strings exceeding the configured deserialization limit are rejected during serialization, preventing Jackson from producing JSON that it would subsequently refuse to deserialize under the same constraints.

For our use case, we would enable this feature by default in JobRunr.

An alternative approach would be to introduce corresponding limits in StreamWriteConstraints, ideally with defaults that align with StreamReadConstraints. This would make it possible to configure serialization and deserialization limits independently when necessary, while avoiding unexpected incompatibilities by default.

This would be useful to us in 2.x, as well as 3.x. Would you consider adding something like this? Or any other suggestions on how to deal with this?

Thanks for your time and for maintaining Jackson!

[pjfanning]

I'd much prefer just adding specific StreamWriteConstraints instead a catch all 'use the StreamReadConstraints' when writing.

[pjfanning]

Oh and this is the wrong repo for this. Jackson-Core is where the streaming is done.

[auloin]

@pjfanning I hope this discussion doesn't lead to an unwelcome PR! If this seems like a worthwhile feature, we're happy to contribute the developer time to implement it.

I'd much prefer just adding specific StreamWriteConstraints instead a catch all 'use the StreamReadConstraints' when writing.

Having corresponding constraints in StreamWriteConstraints would certainly help.

My concern is that the two classes are completely independent, so consumers that need to ensure that their output respects Jackson's read constraints would have to maintain their own mapping and validation logic. Whenever a new read constraint is introduced, that logic could become incomplete unless consumers explicitly update it as well.

With .enable(StreamWriteFeature.ENFORCE_READ_CONSTRAINTS), Jackson could handle this automatically by applying the stricter of the read and write constraints, where applicable. This would avoid duplicating the logic in downstream libraries and make it easier to keep the behavior up to date as new constraints are introduced.

Oh and this is the wrong repo for this. Jackson-Core is where the streaming is done.

Thanks for doing the transfer!

[pjfanning]

-1 from me on StreamWriteFeature.ENFORCE_READ_CONSTRAINTS - becomes a real thorn in our sides - we won't be able to implement any read side constraints without forcing write side work on us too

I think StreamWriteFeature.ENFORCE_READ_CONSTRAINTS is a really bad idea.

[pjfanning]

If you don't like the Jackson constraints, you can always adjust the values.

[cowtowncoder]

Yeah, -1 for using StreamReadFeature limits on writer side. While I can see challenges from user side, architecturally/design-wise I do not want dependencies between input and output sides.

But beyond this there may be a challenge in that limits for lengths might not match, even if using equal values -- as documented in StreamReadConstraints, limit is not strict but approximate, and depends on unit (byte vs char) being used. For JSON this is likely always char, even when using byte-sourced parsers, so not problematic. For binary formats unit may be byte tho -- although this could be fixed if not.
But if units were different, 3 byte UTF-8 can become 1 char; so maintaining accurate check may not be possible.

But with this caveat, adding StreamWriteConstraints limits as counterparts to reader side could be useful, and I think PRs would be acceptable.