typegen directory and events inconsistency

[xmonader]

Noticed that envs don't have the same files

also

• what are the tfchainversions.jsonl files?
• events inconsistency in typegen files?

[DylanVerstraete]

Addressed here: threefoldtech/ledger_chain#814

[sameh-farouk]

Verification note:

Addressed here: threefoldtech/ledger_chain#814

@DylanVerstraete can you point where exactly that was addressed. PR contains A lot on info. also can we address this in this repo docs if possible (at least with link to relative section)

[sameh-farouk]

Addressed here: threefoldtech/ledger_chain#814

That PR is feat(docs): add readmes for tfchain pallets — it doesn't address any of the questions here.

This issue is now fully addressed by PR #207 (feat: automate type generation with append-only version log). Here's a direct answer to each question:

What are the tfchainVersions.jsonl files?

Each line is a JSON object containing the full runtime metadata snapshot for one specVersion, discovered by Subsquid's metadata explorer from a running chain node:

{"specName":"substrate-threefold","specVersion":9,"blockNumber":0,"blockHash":"0x0378...","metadata":"0x6d657461..."}

Typegen reads this file to discover all event type structures across all runtime upgrades. It computes a BLAKE2 hash from each event's SCALE-encoded type structure, and generates isVxx/asVxx accessors in src/types/events.ts. The version label (e.g., v63) is assigned based on the first entry in the JSONL where that hash appears — which is why the file is sorted by specVersion (lowest first).

Previously, each environment had its own JSONL (generated from that network's node), hence the separate typegen/, typegenDevnet/, typegenLocal/, typegenTestnet/ directories shown in the screenshot. PR #207 unified all of these into a single typegen/tfchainVersions.jsonl with 93 specVersions from all 4 networks.

Why did environments have different files?

Three reasons:

1. Not every specVersion is deployed to every network. For example, v121 and v122 might land on devnet only as RCs during feature iteration, then v123 (the release) ships through devnet → qanet → testnet → mainnet. When typegen runs against devnet it sees v121/v122/v123, but against mainnet it only sees v123. So version labels and event accessor branches differ per environment.

2. Devnet has been reset multiple times (tfchain#21, #55, #499). The current devnet starts at v49, losing v9–v48 history. The metadata explorer can only discover what's on-chain now, so a devnet-only JSONL misses the earliest versions. Testnet has the oldest continuous history (from v9).

3. Hand-maintained types had wrong struct field ordering. Because src/types/ was manually edited (copy from src/typesDevelopment/, merge by hand), some interfaces had fields in a different order than the actual Rust struct. This produced incorrect BLAKE2 hashes, creating phantom isVxx branches that never matched at runtime on any network. The code worked by accident — the if/else chain fell through to a later version check with the correct hash. Examples: TwinStored v49, FarmStored/Updated v63, NodeStored/Updated v63 all had phantom hashes.

What PR #207 fixed

• Replaced all per-environment typegen directories with a single unified typegen/tfchainVersions.jsonl (all 4 networks merged, sorted by specVersion)
• Fully regenerated src/types/ from actual chain metadata — correct hashes, correct version labels
• Removed src/typesDevelopment/ (no longer needed)
• Renamed all mapping references to match generated output (e.g., V49→V9, V101→V63, V122→V123)
• Removed dead branches with phantom hashes from wrong field ordering
• Added make typegen / make typegen-add for automated type generation going forward
• Rewrote docs/typeChanges.md with full documentation of the new workflow

See docs/typeChanges.md (introduced in PR #207) for the complete explanation of how type generation works, deployment order, devnet resets, and the history of why manual maintenance was needed.

This issue can be closed once PR #207 is merged.