Strengthen RpcTest::basic to catch casing/schema mismatches with Lotus

[coderabbitai]

Summary

RpcTest::basic (in src/tool/subcommands/api_cmd/api_compare_tests.rs) is too permissive and does not actually compare Forest's response against Lotus's response. This allowed a field-casing bug in Filecoin.NodeStatus (missing #[serde(rename_all = "PascalCase")] on NodeSyncStatus, NodePeerStatus, NodeChainStatus, NodeStatusResult) to go undetected until manual review.

Root cause

• RpcTest::basic_raw sets check_syntax to deserialize the Forest JSON response into T via crate::rpc::json_validator::from_value_rejecting_unknown_fields::<T>.
• However, it sets check_semantics: Box::new(|_, _| true), meaning it never inspects or compares the Lotus response at all.
• Since Forest's own response is generated from T, deserializing it back into T is nearly always trivially true, regardless of field-name casing, ordering, or other schema differences relative to Lotus.
• Only RpcTest::validate / RpcTest::validate_raw / RpcTest::identity perform real cross-comparison (deserializing and comparing/validating both Forest's and Lotus's JSON).

Impact

Any RPC method that only uses RpcTest::basic (rather than identity/validate) can silently drift from Lotus's actual JSON schema (casing, field names, structure) without the test suite catching it, as happened with Filecoin.NodeStatus.

Proposed change

• Make RpcTest::basic/basic_raw also deserialize the Lotus response into T (at minimum), so casing/schema mismatches surface as syntax check failures rather than being silently ignored.
• Optionally, perform a lightweight structural comparison (e.g., same top-level field names/keys) between Forest and Lotus JSON, even without full semantic equality, since some methods (e.g., session/time-based ones) cannot use full identity checks.
• Audit common_tests(), chain_tests(), and other test groups in src/tool/subcommands/api_cmd/api_compare_tests.rs to see which methods could be upgraded from basic to identity/validate for stronger coverage.

Affected area

• src/tool/subcommands/api_cmd/api_compare_tests.rs (RpcTest::basic, RpcTest::basic_raw, RpcTest::validate_raw)

Acceptance criteria

• RpcTest::basic catches at least field-name/casing mismatches between Forest and Lotus responses (i.e., would have failed for the pre-fix NodeStatus result types).
• Existing test suite continues to pass for methods correctly matching Lotus's schema.

References

• PR: fix(rpc): fix Filecoin.NodeStatus input and field #7331
• Discussion: fix(rpc): fix Filecoin.NodeStatus input and field #7331 (comment)
• Requested by: @LesnyRumcajs

[LesnyRumcajs]

Actually I think there's no need to do that on the test level (at least the casing) - we can just walk the OpenRPC doc and see if it's not following CamelCase.

[Osraka]

I checked current main against the proposed OpenRPC approach.

The generated v0 and v1 specs still contain four non-camelCase parameters for Filecoin.StateMinerInitialPledgeForSector: sector_duration, sector_size, verified_size, and tipset_key. The v2 spec does not expose this method because ApiPaths::all intentionally excludes v2.

I can keep this narrow by:

• renaming only the PARAM_NAMES metadata to sectorDuration, sectorSize, verifiedSize, and tipsetKey;
• adding a small test that walks generated OpenRPC method parameters and rejects non-lower-camel names;
• updating the v0/v1 snapshots.

I would not change RpcTest::basic or response schema casing. Does this match the intended scope?

Disclosure: this comment was prepared with Codex assistance and reviewed by me.

[LesnyRumcajs]

This might need some more core team investigation given changing casing might be a breaking change. Some considerations need to be made for Forest. APIs. Thanks for your interest but this issue is not yet ready to be worked on.