[Bug] HugePrimaryKeyStrategy silently converts vertex-property metadata into vertex properties

[contrueCT]

Bug Type (问题类型)

gremlin (unexpected result)

Before submit

• I searched the existing issues and did not find the same problem.

Environment (环境信息)

• HugeGraph Server: current apache/hugegraph master at 431f6e6b
• TinkerPop: 3.5.1
• Backend: backend-independent; the incorrect rewrite happens in a traversal strategy before the vertex is written

Expected and actual behavior (期望与实际表现)

HugePrimaryKeyStrategy folds a single-cardinality AddPropertyStep immediately following addV() into the vertex-creation step.

For this traversal:

g.addV("person").
  property("name", "marko", "country", "cn")

TinkerPop treats country=cn as a meta-property attached to the name vertex property. It does not treat country as a sibling property of the vertex.

HugeGraph currently reports supportsMetaProperties() == false, and HugeVertex.property(...) explicitly throws VertexProperty.Exceptions.metaPropertiesNotSupported() when meta-properties are passed. The expected behavior is therefore an explicit rejection.

The optimization changes that behavior. HugePrimaryKeyStrategy copies every AddPropertyStep parameter other than T.key and T.value into the addV() configuration, then removes the original AddPropertyStep. If country is also a valid schema property, HugeGraph can silently create an ordinary vertex property country=cn instead of rejecting the unsupported meta-property.

This is a data-semantics problem because an unsupported construct is accepted with a different meaning.

Minimal reproduction

Create a schema in which both keys are valid ordinary vertex properties:

schema = graph.schema()
schema.propertyKey("name").asText().create()
schema.propertyKey("country").asText().create()
schema.vertexLabel("person").
       properties("name", "country").
       primaryKeys("name").
       create()

Run the traversal and inspect the resulting vertex:

g.addV("person").
  property("name", "marko", "country", "cn").
  iterate()

g.V().hasLabel("person").has("name", "marko").valueMap(true)

Expected:

• The write is rejected with metaPropertiesNotSupported().
• country=cn is never stored as an ordinary vertex property.

Actual on the affected strategy path:

• The AddPropertyStep is removed.
• country=cn is folded into the vertex-creation step as an ordinary vertex property.

A strategy-level reproduction shows the rewritten traversal as:

AddVertexStartStep({country=[cn], label=[person], name=[marko]})

Source analysis

• TinkerPop 3.5.1 AddPropertyStep separates T.key and T.value from the remaining vertex-property key/value pairs, then passes the remaining pairs to Vertex.property(...) as meta-properties.
• HugeGraph declares that meta-properties are unsupported.
• HugeVertex.property(...) rejects them.
• HugePrimaryKeyStrategy changes the remaining pairs into addV() parameters.

The strategy was introduced in 4b74ab6c in March 2023. The same behavior is still present on the current public master branch. It was noticed while reviewing a TinkerPop 3.8.1 adaptation, but it is not introduced by that upgrade.

Suggested fix and acceptance criteria

When an AddPropertyStep contains vertex-property metadata, HugePrimaryKeyStrategy should not fold that step into addV(). Leaving the step in place preserves the existing explicit rejection from HugeVertex.property(...).

A regression test should verify that:

1. The traversal above throws the unsupported-meta-property exception.
2. The metadata key is never written as an ordinary vertex property.
3. Normal addV().property(key, value) folding still works.
4. Both AddVertexStartStep and mid-traversal AddVertexStep paths preserve the same behavior.

[dosubot]

Good catch — the bug analysis is accurate and well-traced. Here's a quick confirmation from the code:

In HugePrimaryKeyStrategy.apply(), when processing an AddPropertyStep, any parameters that are neither T.key nor T.value are collected into kvList and passed directly to curAddStep.configure(...) [1]. This is the folding that silently promotes meta-property pairs into ordinary vertex properties on the AddVertexStartStep / AddVertexStep.

Meanwhile, HugeVertex.property(...) correctly throws metaPropertiesNotSupported() when objects.length != 0 [2] — but the strategy removes the AddPropertyStep entirely before HugeVertex.property() is ever called, so that guard is never reached.

The fix is straightforward: in the else branch of the T.key/T.value forEach (lines 86–89), instead of accumulating kvList and folding it in, the strategy should bail out and not add the step to removeSteps — leaving the original AddPropertyStep in place so that HugeVertex.property(...) can reject it at execution time. Concretely:

propertyStep.getParameters().getRaw().forEach((k, v) -> {
    if (T.key.equals(k)) {
        kvs[0] = v.get(0);
    } else if (T.value.equals(k)) {
        kvs[1] = v.get(0);
    } else {
        // meta-property detected — mark step as non-foldable
        kvList.add(k.toString());
        kvList.add(v.get(0));
    }
});

if (!kvList.isEmpty()) {
    // Don't fold; leave the step so HugeVertex.property() rejects it
    curAddStep = null;
    continue;
}

curAddStep.configure(kvs);
removeSteps.add(step);

This preserves the existing metaPropertiesNotSupported() exception path without any additional feature logic, and normal addV().property(key, value) folding (where kvList is empty) is unaffected.

Your four regression test criteria (exception thrown, no side-write, normal folding still works, both AddVertexStartStep and AddVertexStep paths covered) are exactly the right test surface.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.