hack: restore JSON API compatibility

[matklad]

See

• feat: rename contract_compile gas parameter #6587 (comment)
• feat: Separate jsonrpc from rest of codebase, to prevent rpcs to breaking due to refactoring. #5516

[matklad]

@frol could you make a judgement call from the perspective of the clients whether this is a sufficient and necessary fix?

From the server perspective, this looks good to me (as in, cheap to support in the future)

[miraclx]

From a client perspective, I think this is better.

[miraclx]

How about we do this instead?

Suggested change

	#[serde(default, rename = "contract_compile_base")]
	pub _unused1: Gas,
	#[serde(default)]
	pub contract_compile_base: Option<Gas>,

[matklad]

I rather like that _unused1 very clearly signals that you shouldn't use that. The Option would also get serialized as null, which I think might break somebody?

[mina86]

Why don’t we set the values to be the same as contract_loading_base and contract_loading_bytes respectively? To me it seems like a proper way to rename a field is to keep the old one for a couple releases to give people time to migrate.

[matklad]

We can do that, but that requires writing custom code which might contain bugs. The current solution is significantly simpler than that.

My understanding that for this code we want to prioritize simplicity over compatibility. I think the problem here is just that the Rust code fails with deserialization error, rather than that someone actually looks at the old field.

[frol]

Looks good to me

[mina86]

I’m not thrilled that we’re start returning zeros to people to be honest.

[matklad]

I can see that :)

My overall hope is that there's some movement to fix #5516 (#6851, #6853), so hopefully this class of errors will be soon fixed by virtue of having a well-defined and separate API layer.