Detect missing deserializer before hitting JSON "slow path" under polymorphism

[alshain]

Describe the bug

When attempting to decode data that contains unknown types (e.g. generated by a newer version of our application), the StreamingJsonDecode abandons streaming and tries to build the entire (huge) structure in-memory using JsonObject etc, which would ultimately fail anyway because the deserializer simply isn't available.

I think it'd be possible to error out earlier and not fall back to the non-streaming approach in such a case.

I've tracked this down to this fragment in StreamingJsonDecode:

            val discriminator = deserializer.descriptor.classDiscriminator(json)
            val type = lexer.peekLeadingMatchingValue(discriminator, configuration.isLenient)
            var actualSerializer: DeserializationStrategy<Any>? = null
            if (type != null) {
                actualSerializer = deserializer.findPolymorphicSerializerOrNull(this, type)
            }
            if (actualSerializer == null) {
                // Fallback if we haven't found discriminator or serializer
                return decodeSerializableValuePolymorphic<T>(deserializer as DeserializationStrategy<T>)
            }

Suppose type != null because we did find the discriminator, but actualSerializer == null because the serializer isn't known in the current application version. Is there even a point to try to fallback to the "slow path"?

It'd be nice if you could error out right then and there before entering the slow-path.

Are there cases where it's required to enter this code-path when you find the discriminator but don't find a deserializer? From my reading of the code, you always error out here:

val actualSerializer = deserializer.findPolymorphicSerializerOrNull(this, type)
        ?: throwSerializerNotFound(type, jsonTree)

[sandwwraith]

Hi, thanks for your investigation and detailed report. Yes, I think you're right — when the serializer can't be found by the discriminator, it is an error anyway. The only difference is that throwSerializerNotFound accepts jsonTree to append it to the error message. But this can also be done directly from the input string.
By the way, do you have any benchmarks or measurements on how this affects your application preformance?

[alshain]

@sandwwraith Awesome, thanks!

By the way, do you have any benchmarks or measurements on how this affects your application preformance?

Not really, we only noticed that the slow-path exists because we went OOM because of it. We might not have noticed otherwise. We deserialize 120MiB of JSON and it's not exceedingly fast in the first place.

But thanks to the OOM, we can see that it took at least 1.2 gigs of additional memory but I don't know much longer or more memory it would have taken before finishing.

Ideally, it wouldn't print the remaining 119MiB of JSON into the log :)

[sandwwraith]

But thanks to the OOM, we can see that it took at least 1.2 gigs of additional memory but I don't know much longer or more memory it would have taken before finishing.

That's sufficient evidence, thanks. Not sure how you are expecting it to be deserialized when class discriminator is known, though :)

Ideally, it wouldn't print the remaining 119MiB of JSON into the log

Of course, there's truncation:

kotlinx.serialization/formats/json/commonMain/src/kotlinx/serialization/json/internal/JsonExceptions.kt

Line 78 in 60c632c

private fun CharSequence.minify(offset: Int = -1): CharSequence {

[alshain]

Not sure how you are expecting it to be deserialized when class discriminator is known, though :)

Under streaming, it works just fine. The resulting object graph is ~250MiB in size according to a heap dump.

[alshain]

@sandwwraith Thanks for implementing the fix. Do you have a timeline on the release? 😇

[sandwwraith]

@alshain A week or two after Kotlin 1.9.20

[alshain]

Thank you ❤️