When creating Receipts to return over API, a one-off []map[string]interface{} structure is defined to contain the returnable fields. These structures are tested by marshaling individual receipts and comparing to an expected content from JSON test-files.
Separately, in core, types.Receipt structures are used to represent Transaction Receipts. These are tested by marshaling and unmarshalling sample structures.
However, there isn't testing which links these two structures. It is possible that a given version of geth might emit Receipts over its API which can't be unmarshalled by that same version of geth. If ever there is a change to either the API structure or the types.Receipt structure, this incompatibility may occur. When it does, there should exist testing which exposes this.
This change simply adds a round-trip marshal-unmarshal from the API structure to a types.Receipts. This confirms that the emitted API structure is compatible as a types.Receipts.
Testing
Tested this manually in the following ways:
Added a new field to types.Receipt which is required by the codec. Observed that the API test previously would pass (because the API structure matches its own expected output), but with the new testing this now fails, highlighting the missing field.
Changed the type of an existing field in the API. Existing checks against the expected-JSON file failed, but once that was updated, this new check is required to show that the type is not suitable for types.Receipt
Added additional fields to the API structure. Existing checks against the expected-JSON file failed, but once that was updated, this new check is required to show that the type is not expected for types.Receipt
Reasoning
Geth's own API should be compatible with its ethereum spec definition of structures. Therefore, while these structures are separately managed, it makes sense to include testing which confirms their own internal compatibility.
When creating Receipts to return over API, a one-off
[]map[string]interface{}structure is defined to contain the returnable fields. These structures are tested by marshaling individual receipts and comparing to an expected content from JSON test-files.Separately, in
core,types.Receiptstructures are used to represent Transaction Receipts. These are tested by marshaling and unmarshalling sample structures.However, there isn't testing which links these two structures. It is possible that a given version of
gethmight emit Receipts over its API which can't be unmarshalled by that same version of geth. If ever there is a change to either the API structure or thetypes.Receiptstructure, this incompatibility may occur. When it does, there should exist testing which exposes this.This change simply adds a round-trip marshal-unmarshal from the API structure to a
types.Receipts. This confirms that the emitted API structure is compatible as atypes.Receipts.Testing
Tested this manually in the following ways:
types.Receiptwhich is required by the codec. Observed that the API test previously would pass (because the API structure matches its own expected output), but with the new testing this now fails, highlighting the missing field.types.Receipttypes.ReceiptReasoning
Geth's own API should be compatible with its ethereum spec definition of structures. Therefore, while these structures are separately managed, it makes sense to include testing which confirms their own internal compatibility.
OP would have benefitted from this testing when we added new L2 fields in this PR: https://github.com/ethereum-optimism/op-geth/commit/3653ceb09fc2025d617c6b1033ab8d61a818f67c . The fields were already defined in the
types.Receiptstructure, but they were stillbig.Int, meaning this API structure is not compatible with its own Receipt. (this was later fixed in subsequent PR https://github.com/ethereum-optimism/op-geth/commit/6b2bf0faed56d71d7a91a87703bee9551554b6ea)