kotlinx.serialization icon indicating copy to clipboard operation
kotlinx.serialization copied to clipboard

Add way to log unknown keys when ignoreUnknownKeys is enabled

Open paulhobbel opened this issue 1 year ago • 3 comments

What is your use-case and why do you need this feature? We are building a platform that implements OCPI (a protocol that is used in the EV industry). Even though OCPI is a "standard", companies tend to add extra information to messages.

Because of this we have ignoreUnknownKeys set to true. We would still like to know which keys had been ignored so we can consider whether we should add these in the future as well. We used Jackson before and in Jackson there was a DeserializationProblemHandler that you could register as module.

The solution we have in place as of right now is extending the StringFormat and have a custom try-catch clause around decodeFromString and the ignoreUnknownKeys set to false.

Describe the solution you'd like Provide a way to configure some sort of problem handler, this could already be in the form of a lambda function you pass to the Json builder.

Someting as follows maybe?

fun reportOnUnknownKey(key: string, descriptor: SerialDescriptor) {
   logger.warn("Unknown key '$key' in ${descriptor.serialName}"
}

val jsonFormat =
    Json {
        ignoreUnknownKeys = true
        explicitNulls = false
        onUnknownKey = reportOnUnknownKey
    }

paulhobbel avatar Jun 03 '24 13:06 paulhobbel

My Xml format supports this, but I found that using custom types for handling this does not scale well. Instead it has a policy parameter where (various) behavioural functions are provided. In the case of Json the functions that come to mind are handling unknown keys. Handling "invalid" values (e.g. strings instead of Int). The algorithm that determines the key name (for example converting camel case to snake case).

pdvrieze avatar Jun 03 '24 14:06 pdvrieze

Can't this be covered by #1978? By using additional map in the object itself, you can still log them when map is non-empty

sandwwraith avatar Jun 13 '24 16:06 sandwwraith

The xml use case for the policy function is mainly to support error correction (including the various "almost xml" variants out there that real world code has no choice but to deal with). The ability to log the key is a side effect. I don't think that json really has such a big problem with key mismatch (no namespaces to get wrong, etc.)

pdvrieze avatar Jun 13 '24 18:06 pdvrieze

Duplicate of #453

sandwwraith avatar Nov 27 '24 18:11 sandwwraith