[Bug] schema ~create_time userdata round-trips Date as String after cache reload

[dpol1]

Bug Type (问题类型)

logic (逻辑设计问题)

Before submit

• 我已经确认现有的 Issues 与 FAQ 中没有相同 / 重复问题 (I have confirmed and searched that there are no similar problems in the historical issue and documents)

Environment (环境信息)

• Server Version: 1.0.0 (Apache Release Version)
• Backend: RocksDB x nodes, HDD or SSD
• OS: xx CPUs, xx G RAM, Ubuntu 2x.x / CentOS 7.x
• Data Size: xx vertices, xx edges

Expected & Actual behavior (期望与实际表现)

HugeGraph automatically writes internal schema userdata Userdata.CREATE_TIME ("~create_time") as a java.util.Date when creating schema elements.

Expected

After a schema element is reloaded from backend storage, this value should still be a java.util.Date, consistent with existing schema tests that cast
schemaElement.userdata().get(Userdata.CREATE_TIME) to Date.

Actual

After a backend/store reload, schemaElement.userdata().get(Userdata.CREATE_TIME) can be returned as a String timestamp instead of java.util.Date.

This is exposed more clearly after PR #3011 because cross-JVM schema-cache-clear events cause remote server nodes to invalidate and reload schema from backend
storage. The publishing JVM may not observe the issue because it can keep using the in-memory schema object and, with the self-echo skip, does not reload its own
freshly-created schema.

Suspected cause

The schema userdata serialization path writes Date values as strings, but the schema deserialization path does not convert the internal ~create_time value back to
java.util.Date.

Scope

Out of scope for PR #3011. That PR only changes runtime schema-cache invalidation propagation. It does not change persisted schema data or fix schema userdata
serialization round-trips.

Minimal repro sketch

1. Start two HugeGraph server JVMs sharing the same graph / meta / backend.
2. On Server A, create a schema element (e.g. a property key or vertex label).
3. Ensure Server B reloads that schema from backend storage after a schema-cache-clear event.
4. On Server B, inspect schemaElement.userdata().get(Userdata.CREATE_TIME).
5. Expected type: java.util.Date — actual type: String.

Vertex/Edge example (问题点 / 边数据举例)

Schema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)

[dosubot]

Your analysis is correct. The root cause is that all backend serializers (Text, Binary, MySQL, Cassandra) deserialize userdata using JsonUtil.fromJson(userdataStr, Map.class), which gives Jackson no type information about the values [1] [2] [3] [4]. Even though a custom DateDeserializer is registered with format "yyyy-MM-dd HH:mm:ss.SSS" [5], it's only invoked when the target type is explicitly Date.class — not when deserializing to a raw Map.

During creation, SchemaTransaction.setCreateTimeIfNeeded() correctly stores a real java.util.Date via DateUtil.now() [6], and the serialization side properly converts it to a formatted string. But on the read path, the string is never converted back.

The simplest fix would be to post-process userdata after deserialization — check for the ~create_time key and convert the String value back to Date using DateUtil.parse() [7]. This would need to be applied in the readUserdata() path of each serializer (or in a shared utility). Multiple test cases already expect a Date return type and would throw ClassCastException otherwise [8] [9].

Worth noting: this bug likely existed before PR #3011 but was rarely observed in single-JVM deployments because the in-memory schema object (with the correct Date type) was typically used without needing a full backend reload.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[dpol1]

Thanks @dosu, this matches my understanding.

The important point is that the write path stores Userdata.CREATE_TIME as a real java.util.Date, but the backend read paths deserialize userdata into a raw Map, so the formatted timestamp is never converted back to Date.

I agree the fix should probably be centralized if possible, rather than repeated independently in every serializer: after deserializing userdata, normalize the internal Userdata.CREATE_TIME entry from String back to Date.

This also explains why the issue existed before #3011 but became easier to observe with cross-JVM schema-cache invalidation: remote nodes are forced to reload schema from backend storage instead of reusing the publishing JVM's in-memory schema object.

[dosubot]

Agreed on centralizing the fix. The good news is that all four serializers (Text, Binary, MySQL, Cassandra) converge on calling SchemaElement.userdata(String key, Object value) for each deserialized entry [1]. That single-key setter is the natural place to add normalization — something like:

public SchemaElement userdata(String key, Object value) {
    E.checkNotNull(key, "userdata key");
    E.checkNotNull(value, "userdata value");
    if (Userdata.CREATE_TIME.equals(key) && value instanceof String) {
        value = DateUtil.parse((String) value);
    }
    this.userdata.put(key, value);
    return this;
}

This avoids touching each serializer independently and covers all backend paths in one place. The Userdata class itself just extends HashMap<String, Object> [2] with no instance-level normalization, so the SchemaElement setter is the better location.

One consideration: if other internal userdata keys are added in the future with non-primitive types, this pattern could be extended to a small normalization registry rather than growing into a chain of if statements.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.