MetaObjectSerializer: DATE branch serializes the containing object, causing unbounded recursion

[dmealing]

Summary

MetaObjectSerializer.writeField passes the containing object to context.serialize(...) in the DATE branch instead of the field's value. Because the serializer is registered against the object's own class, that call re-enters the same serializer with the same instance, so any MetaObjectAware VO carrying a field.date / field.timestamp self-recurses without bound and dies with a StackOverflowError.

Location

server/java/metadata/src/main/java/com/metaobjects/io/object/gson/MetaObjectSerializer.java

protected void writeField(MetaObject mo, MetaField mf, Object vo,
                          JsonObject jsonObject, JsonSerializationContext context) {
    String name = getJsonName(mf);
    switch (mf.getDataType()) {
        case BOOLEAN:
            jsonObject.addProperty(name, mf.getBoolean(vo));   // reads the FIELD off vo
            break;
        ...
        case DATE:      // TODO: consider custom DATE serialization
            jsonObject.add(name, context.serialize(vo));       // ← serializes vo ITSELF
            break;

Every sibling branch extracts the field value with an mf.getX(vo) accessor. DATE alone hands vo — the whole containing object — straight back to Gson.

Why it recurses

MetaObjectGsonInitializer registers a MetaObjectSerializer for the VO's concrete class (and for its interface, when the object class is one):

builder.registerTypeAdapter(clazz, new MetaObjectSerializer(mo));

So the cycle is:

serialize(vo) → writeObject(mo, vo, …) → writeField(mo, mf, vo, …) → case DATE: → context.serialize(vo) → Gson dispatches on vo.getClass() → the same registered MetaObjectSerializer → serialize(vo) → …

There is no base case, so it terminates only by exhausting the stack.

Impact

StackOverflowError is an Error, not an Exception. Callers that wrap serialization in catch (Exception …) — the normal shape for a best-effort/telemetry write — do not catch it, so it propagates out of the serialization seam and kills whatever operation was in flight rather than degrading to a skipped write. Any adopter serializing a VO with a date-typed field hits this on the first such object.

Suggested fix

Extract the field value the same way every other branch does. MetaField.getDate(Object) already exists:

case DATE:
    jsonObject.add(name, context.serialize(mf.getDate(vo)));
    break;

Worth deciding at the same time what the intended wire form is — the existing // TODO: consider custom DATE serialization suggests this branch was never finished. Gson's default Date handling is locale-dependent; an ISO-8601 string would round-trip more predictably. Note the deserializer currently groups case DATE: with case LONG:, so whichever form is chosen should be matched there.

Versions

Found against 7.20.11 (Maven Central, Java line). Still present on the current Java line at 7.20.16 — the file's last change was an unrelated hygiene commit.

Notes

Not currently reachable in the adopting codebase where this was found, because no date-typed field is declared in the metadata that goes through this path. Filing it because it is a latent trap: the first field.date anyone adds to a serialized VO turns a working system into a crashing one, with a stack trace that points at Gson rather than at the metadata change that caused it.

[dmealing]

Fixed and released in 0.21.1 (npm 0.21.1 · PyPI 0.21.1 · NuGet 0.21.1 · Maven 7.21.1).

What shipped

Commit	Change
94a9f400	The recursion fix + TemporalWireFormat (the ISO-8601 wire form), with a case DATE: split in both readers
daa8d677	Two Gson adapter-wiring defects, fixed atomically because they masked each other
026bc342, 0ba2e030	Serializer write side honors mf.isArrayType()
4f46470d, 312f1bda	The matching storage gap: MetaField.setObject and DataConverter.DATE_ARRAY
f8e10c39	Locale.ROOT on the fraction formatter + a false-comment correction

Blast radius was wider than the report

TimestampField is also DataTypes.DATE, so field.timestamp crashed too — and OMDB's typed-jsonb codec serializes through this same serializer, so a field.object @storage: jsonb value-object declaring any temporal field crashed an OMDB INSERT/UPDATE. It stayed hidden because the one jsonb fixture in the corpus happens to carry no temporal field. The branch also fired when the value was null, since it never read the field at all.

The wire form is the cross-port contract, not a new invention

It matches fixtures/persistence-conformance/normalization.md: field.date → "2026-06-03"; field.timestamp @localTime → no Z; field.timestamp → UTC instant with Z; millisecond fraction, trailing zeros stripped, omitted when zero. Readers still accept legacy epoch-millis numbers, which is what kept this a PATCH.

Found while fixing it

• An array-valued field round-tripped as corrupt data in both directions — written as the comma-joined "a,b", and unstorable because setObject converted via the scalar type while DataConverter had no DATE_ARRAY at all.
• A locale-dependent String.format("%03d", …) in the new helper would have written non-Latin digits into the wire form under a non-Latin default locale — output this layer's own reader cannot parse back, landing silently in jsonb columns. Caught in review, fixed, and pinned with a locale regression test.
• Four separate comments asserting behavior that was not true, including the one that caused a sibling bug. Each was corrected.

Deliberately not in scope

BYTE_ARRAY/SHORT_ARRAY remain unsupported — field.byte/field.short were cut from the metamodel as non-functional stubs. The deserializer's numeric-array widening (Gson's List.class yielding List<Double>) is unchanged. And the OMDB jsonb temporal path — the motivating blast-radius claim — still has no regression test at any level; that is the one loose end worth picking up next.