Lossless stringify and parse do not handle Date, Map, or Set

[jwulf]

Any variables that are managed in application code as type Date, Map, or Set will not be correctly serialised.

Claude 3.5 recommends the following patch for Date:

if (value instanceof Date) {
  // Handle Date objects by converting them to an ISO string
  newObj[key] = value.toISOString();
}

And suggests flatted, or json-stringify-safe for Map and Set.

I checked those out, and they are for circular JSON. We are not going to support that - we've going to throw on circular JSON. And they don't have any support for Map or Set.

An issue here is that even with the patch that Claude suggests, we are not going to get a reviver without metadata. So if users are dealing with a Date object, then send it to the Camunda 8 engine, when it next shows up (at the end of a process or in a worker) it will be of type string.

So: we should throw when passed a Date, Map, or Set, and make the de/serialization to string the concern of the application.

And as a bonus, I could make a Dto annotation that de/serializes those types.

So when encountering a Date, Map, or Set, the stringifier checks if it is a LosslessDto and has the correct metadata field. If it does, we assume that the user is leaning into the Dto framework to handle this concern, and do a transform.

Let me do a spike on this and see how practical it is. I'd like to support native types.

The risk area is that a user sends data with a Dto with the correct metadata, but elsewhere receives it with a different Dto and it deserialises as a different type. We can throw if we are stringifying something with insufficient metadata, but we can't know when parsing it.

[jwulf]

I went lowest-orbit possible.

Because I can't reliable rehydrate across the system boundary, I'm going to make it explicitly the concern of the application.

We throw (with a helpful message) if we get a Date, Map, or Set in variables.