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

[bitflicker64]

Bug Type (问题类型)

None

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 (期望与实际表现)

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

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

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

[github-actions]

Issue Analysis and Proposed Solution

The issue described is related to the serialization and deserialization of schema userdata, specifically the ~create_time field, which is initially stored as a java.util.Date object but is returned as a String timestamp after a schema element is reloaded from backend storage.

Cause

The cause of this issue lies in the mismatch between the serialization and deserialization processes for schema userdata. When schema elements are written to the backend, the userdata map is serialized, converting the Date object to a JSON string. However, upon retrieval, this string is not explicitly converted back to a Date object.

Solution Approach

To fix this bug, we need to modify the deserialization path for Userdata.CREATE_TIME to explicitly convert the String timestamp back into a java.util.Date object. This can be achieved through:

1. Type-aware deserialization: Modify CassandraSerializer.readUserdata() to check if the key is Userdata.CREATE_TIME and use a DateFormat (like HugeGraphSONModule.DATE_FORMAT) to parse the string into a Date object.
2. Custom deserializer: Implement a custom deserializer for Date objects when they are part of the userdata map.

Implementation

The SchemaMetaManager is responsible for adding and retrieving schema elements from the meta backend. Its getPropertyKey() method uses JsonUtil.fromJson(content, Map.class) to deserialize the schema content, populating the userdata map. This is the point where the String to Date conversion for ~create_time should occur.

Next Steps

To resolve this issue, the proposed solution should be implemented and tested to ensure that the ~create_time field is correctly deserialized as a java.util.Date object after reloading schema elements from backend storage.

Note: I'm an AI bot powered by DeepWiki + Groq, here to assist with your questions. If you have any follow-up questions or need further clarification, feel free to quote-reply this message and ask away!

---

✅ Powered by DeepWiki + Groq — answer based on actual repo documentation.

[bitflicker64]

assign me

[bitflicker64]

/assign-check @bitflicker64 7d

[bitflicker64]

/assign-check @bitflicker64 7d

[github-actions]

🤖 @bitflicker64 hasn't forked this repo.

Not gonna let you work on it buddy — fork the repo first, then someone can run /assign-check for you again.

Fork it here: https://github.com/bitflicker64/incubator-hugegraph

[bitflicker64]

/assign-check @bitflicker64 7d

[bitflicker64]

/assign-check @bitflicker64 7d

[github-actions]

🤖 Contributor Bio — @bitflicker64

having fun building stuff ....

Field	Value
🍴 Forked repo	✅ Yes
📅 Account created	11mo ago
👥 Followers	27
📦 Public repos	57
📍 galaxy
🏢 Student
🔨 Commits in this repo	0
✅ PRs merged in this repo	0
📝 Issues opened in this repo	7

---

Requested deadline: 7 days

A maintainer can approve with:

/approve-assign @bitflicker64

🤖 Assign Bot — bio pulled from GitHub API

[bitflicker64]

/approve-assign @bitflicker64

[github-actions]

✅ @bitflicker64 has been assigned by @bitflicker64.

⏰ Deadline: 2026-05-14 (7 days from now)

Please post an update at least once before the deadline. The bot will warn you 3 days before and unassign if there's no activity by 2026-05-14.

🤖 Assign Bot

[github-actions]

⚠️ Deadline reminder — @bitflicker64

You have 3 days left (deadline: 2026-05-14) to post an update on this issue.

If you need more time or can't continue, please let the maintainers know so someone else can pick this up.

🤖 Assign Bot