inconsistent node certification type between chain and graphql

[0oM4R]

threefoldtech/zos_sdk_ts#3387
threefoldtech/zos_sdk_ts#3340

[0oM4R]

I tried to create node with diy, then update the certificate using nodeCertificationSet event and it got updated normally
looks like that node has been updated before handling this event in graphql and need to be updated manually

[0oM4R]

using this script i was able to collect all conflicts
the only network that have conflicts is devnet : 26 nodes with different certifications, 12 of them are UP

NODE	GRAPHQL	CHAIN	STATUS
62	Diy	Certified	down
74	Diy	Certified	down
75	Diy	Certified	down
102	Diy	Certified	down
170	Diy	Certified	down
126	Diy	Certified	down
178	Diy	Certified	down
180	Diy	Certified	down
181	Diy	Certified	down
184	Diy	Certified	down
186	Diy	Certified	down
177	Diy	Certified	up
179	Diy	Certified	up
173	Diy	Certified	down
182	Diy	Certified	down
175	Diy	Certified	down
176	Diy	Certified	up
168	Diy	Certified	up
174	Diy	Certified	up
163	Diy	Certified	up
165	Diy	Certified	up
166	Diy	Certified	up
144	Diy	Certified	up
146	Diy	Certified	up
150	Diy	Certified	up
145	Diy	Certified	up

[sameh-farouk]

Root cause identified

nodeStored in the GraphQL processor hardcodes certification = Diy and never reads the actual certification from the NodeStored event payload — even though the event includes it (as certificationType in v28/v43, certification in v63+).

How to reproduce

1. Have a farming policy with node_certification: Certified
2. Create a node on that farm
3. On-chain: _create_node sets new_node.certification = farming_policy.node_certification → Certified
4. Chain emits NodeStored with the full node struct including certification: Certified
5. Processor receives the event but ignores the certification field, stores Diy
6. No NodeCertificationSet event is emitted on node creation (never has been, in any spec version)
7. GraphQL shows Diy, chain shows Certified

The mismatch persists until either:

• set_node_certification is called (emits NodeCertificationSet which the processor handles correctly)
• update_node is called on a v28+ runtime (the nodeUpdated handler does read certification from the event)

Verification

All 26 affected devnet nodes are associated with farming policy 3, which has nodeCertification: Certified. This confirms the root cause — nodes created under a Certified policy get the correct certification on-chain but the processor ignores it and stores Diy.

Chain-side investigation

Traced the certification lifecycle across all pallet versions:

Spec	Change	Event emitted
Pre-v62	CertificationType era. set_node_certification was sudo-only, emitted only NodeUpdated. No dedicated certification event.	NodeUpdated
v62	NodeCertificationSet event introduced. Type renamed to NodeCertification. AllowedNodeCertifiers added.	NodeUpdated + NodeCertificationSet
v107	create_node now assigns farming_policy.node_certification — nodes can be created as Certified. No NodeCertificationSet on create.	NodeStored only
v113	update_node resets Certified→Diy if resources changed.	NodeCertificationSet
v114	Council/Root can call set_node_certification.	NodeUpdated + NodeCertificationSet

_create_node has never emitted NodeCertificationSet in any spec version. The only way to know a node's initial certification is to read the NodeStored event payload.

Processor-side investigation

All code paths that set certification on a Node entity:

Handler	Event	Reads certification?
nodeStored	NodeStored	NO — hardcodes Diy (line 75). This is the bug.
nodeUpdated v9	NodeUpdated	No — v9 Node struct has no certification field (correct)
nodeUpdated v28/v43	NodeUpdated	Yes — reads certificationType.__kind
nodeUpdated v63/v105/v118	NodeUpdated	Yes — reads certification.__kind
nodeCertificationSet	NodeCertificationSet	Yes — reads certification.__kind via asV63 (single hash, covers all versions since v63)

Why only devnet showed mismatches

Devnet farming policies are more likely to have node_certification: Certified. On mainnet/testnet most policies use Diy, so the hardcoded default happens to be correct by accident.

Fix

Read certification from the NodeStored event payload for v28+ in the version-specific blocks of nodeStored, using parseNodeCertification — the same pattern already used in nodeUpdated. Will follow up with a PR.