关于"leadto"和逻辑结果表达“createNode.../createEdge...”不生效的问题

[lorinwu]

Hi，

我正在阅读手册，并在努力实现supplychain的例子，重点想学Action关键字的效果，但经过多次测试，当前0.8版本的kag自带的该例子中，没有实现action的结果，通过

事件影响分析：

knext reasoner execute --dsl "
MATCH
    (s:SupplyChain.ProductChainEvent)-[:leadTo]->(o:SupplyChain.CompanyEvent)
RETURN
    s.id, s.subject, o.subject, o.name
"

返回为空

(KAG) ➜  supplychain git:(master) ✗ knext reasoner execute --dsl "
MATCH
    (s:SupplyChain.ProductChainEvent)-[:leadTo]->(o:SupplyChain.CompanyEvent)
RETURN
    s.id, s.subject, o.subject, o.name
"
      0          1          2       3
0  s.id  s.subject  o.subject  o.name

[JJUN99]

We ran the same supplychain example on the same 0.8 server image and root-caused several server-side bugs in this area, so sharing findings that may explain your empty result.

In our environment the first hop did work out of the box (ingesting the ProductChainEvent created 47 CompanyEvent vertices with leadTo edges), so a completely empty result suggests the rule didn't fire at all. Things worth checking, in order:

1. Were the concept rules registered? knext schema reg_concept_rule --file ./schema/concept.rule must run after knext schema commit.
2. Stale builder checkpoints: the KAG builder keeps *ckpt* directories next to builder/, and on re-runs it silently skips records it has already seen — so re-indexing after a DB reset produces nothing. Delete them before re-running indexer.py.
3. Swallowed errors: rule-execution failures never reach the client or docker logs. Look at /logs/openspgapp/common-error.log inside the server container — that's where we found the NPE described in fix(reasoner): store business id as property on DDL-created vertices #622.

Even once the first hop works, we found the chain still breaks server-side:

• fix(reasoner): store business id as property on DDL-created vertices #622 — vertices created by a rule Action carry no id property, so follow-up rule runs on them die with a silently-swallowed NPE and the generated events lose their belongTo classification.
• Concept-level event propagation always stops after one hop #623 — generated records aren't standardized (e.g. subject property → edge) until after the propagation pass, so recursive propagation (cost rise → profit drop) never matches and every chain stops after one hop.
• fix(cloudext): do not JSON-encode scalar String property values #621 — string properties are stored double-JSON-encoded, breaking numeric constraints in rules.

With #621/#622 applied plus the change proposed in #623, a single ProductChainEvent ingestion materializes the full chain (47 cost-rise + 47 profit-drop events) in our tests, and the DSL query in your report returns the expected rows.