[Bug] GraphSpace, graph and store isolation do not work with HStore in HugeGraph 1.7.0

[P1ckupschen]

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.7.0 (Core 1.7.0, REST API 0.71.0.0, Gremlin 3.5.1)
• Backend: HStore, one PD + one Store + one Server
• Docker images: hugegraph/server:1.7.0, hugegraph/pd:1.7.0, hugegraph/store:1.7.0
• Deployment: Docker Compose on a Linux server through 1Panel
• Authentication: enabled
• Server config: usePD=true; pd.peers=hugegraph-hstore-pd:8686
• Graph config: backend=hstore; serializer=binary; task.scheduler_type=distributed
• Store config: each graph uses a unique store name
• Data directories: reproduced after rebuilding with completely fresh PD and Store bind directories

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

Description

GraphSpace isolation does not work in this HStore deployment.

Two graphs are created in two different GraphSpaces. The GraphSpace names, graph names, and store names are all different. However, a vertex inserted only into graph A in GraphSpace A can also be queried from graph B in GraphSpace B.

This reproduces through direct HugeGraph REST API calls, without any application code, SDK cache, or reverse proxy. GraphSpace and schema metadata appear separate, but the underlying graph data is shared or reused.

Steps to reproduce

1. Start Server, PD, and Store with completely fresh data directories.
2. Confirm that only the DEFAULT GraphSpace exists.
3. Create two GraphSpaces with auth=true: curl_iso_a_<unique_id> and curl_iso_b_<unique_id>.
4. Create a different graph and store in each GraphSpace: graph_a_<unique_id> and graph_b_<unique_id>.
5. Create equivalent property keys and vertex labels in both graphs.
6. Insert one uniquely named marker vertex only into graph A.
7. Query all vertices from graph A.
8. Query all vertices from graph B.

All GraphSpace, graph, store, property-key, label, and marker names are newly generated for every test run.

Expected behavior

Graph A returns the inserted marker. Graph B must return:

{"vertices":[]}

Graphs in different GraphSpaces with different graph and store names must not share data.

Actual behavior

Graph B unexpectedly returns the vertex inserted only into graph A.

A second test used completely new GraphSpace, graph, store, property-key, vertex-label, and marker names. The newly created graph also returned data from the first test run, and the older vertex was exposed using the new schema label.

Therefore, GraphSpace, graph, and store isolation all appear ineffective with HStore 1.7.0. This prevents multi-tenant isolation and can expose one tenant's data to another.

This appears separate from #2912, which addresses an exception during dynamic graph creation.

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

// Inserted only into graph A:
POST /graphspaces/{space_a}/graphs/{graph_a}/graph/vertices

{
  "id": "1:only_a_19077_27057",
  "label": "iso_person_19077_27057"
}

// Query graph A:
GET /graphspaces/{space_a}/graphs/{graph_a}/graph/vertices

{
  "vertices": [
    {
      "id": "1:only_a_19077_27057",
      "label": "iso_person_19077_27057"
    }
  ]
}

// Query graph B (unexpectedly returns graph A data):
GET /graphspaces/{space_b}/graphs/{graph_b}/graph/vertices

{
  "vertices": [
    {
      "id": "1:only_a_19077_27057",
      "label": "iso_person_19077_27057"
    }
  ]
}

// Second run with completely different names:
{
  "vertices": [
    {
      "id": "1:only_a_19077_27057",
      "label": "iso_person_23806_7305"
    },
    {
      "id": "1:only_a_23806_7305",
      "label": "iso_person_23806_7305"
    }
  ]
}

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

[dosubot]

Hi @P1ckupschen! I'm Dosu and I'm helping the HugeGraph team.

This looks like it's related to a confirmed bug in HStore's graph lifecycle management. Issue #3090 [1] documents that HstoreSessionsImpl.clear() does not remove the graph from the static infoInitializedGraph set, causing incomplete delete/recreate lifecycle state. While that issue was framed around test failures, the same underlying mechanism is likely responsible for what you're seeing in production.

Here's why this could cause the cross-GraphSpace data leakage you're observing:

• HStore isolates graphs using a composite database/store identifier registered with PDClient for partition allocation. Each graph gets its own HstoreSession opened against that graph name [2].
• During graph initialization, the system checks a JVM-wide static infoInitializedGraph set to decide whether to register the graph with PDClient via setGraph(). If a graph name is already in that set (from a previous creation), the registration step is skipped — potentially reusing stale partition mappings [3].
• Additionally, issue Track HStore core-test exclusions and property codec mismatch #3090 confirms that schema cleanup uses asynchronous deletion with only a 100ms wait, allowing schema tasks and cache-clear events to cross graph boundaries [1].

The fact that your second test run returned vertices from the first run — even with completely different GraphSpace, graph, store, and schema names — strongly suggests the underlying storage partitions are being reused rather than freshly allocated. This aligns with the infoInitializedGraph lifecycle bug: once a graph partition exists, new graphs may inadvertently share it.

Issue #3090's acceptance criteria explicitly require "Multi-graph schema isolation passes" and "Repeated clear and recreate tests pass for at least 50 iterations without cross-test tasks or stale initialization state" [1], which directly addresses the class of problem you've reported.

You may want to track #3090 for progress on the fix. Your report adds valuable evidence that this isolation failure affects not just tests but actual multi-tenant deployments with separate GraphSpaces.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.