Error when sending a transaction

[Sliman4]

When sending any transaction with NONE or INCLUDED finality, I'm getting this error with near-api 0.8.3:

TransactionError(Critical(TransportError(Invalid Response Payload (b"{\"jsonrpc\":\"2.0\",\"result\":{\"final_execution_status\":\"NONE\"},\"id\":\"0\"}"): data did not match any variant of untagged enum JsonRpcResponseForRpcTransactionResponseAndRpcTransactionError)))

[frol]

@r-near @vsavchyn-dev Just FYI, the send_tx method can return two drastically different responses. When wait_until is set to EXECUTED / FINAL in the request, the node has the transaction and its execution results, so it returns them, but for wait_until NONE / INCLUDED, the blockchain has not yet executed it, so there are no results to return and as such it returns a totally different payload. Please, update the OpenAPI spec to reflect it and then update the near-openapi-client-rs to reflect that.

[r-near]

Please, update the OpenAPI spec to reflect it

The spec is auto-generated, right? So we'd need to update the generator, or figure out the bug in that part of the codebase?

[r-near]

Also I see the client library is in someone's personal repo? https://github.com/polyprogrammist/near-openapi-client

[frol]

@r-near The spec is auto-generated, but it is not clear if the bug is on the nearcore spec generation side or in the client generation from the spec side. Identify that first.

Also I see the client library is in someone's personal repo?

It is. As I flagged it to you, we wanted to replace the near/near-jsonrpc-client-rs with that codebase and release new near-jsonrpc-client-rs crate to align with the other packages naming (near-jsonrpc-client-ts, near-jsonrpc-client-swift, near-jsonrpc-client-kotlin)

[r-near]

The issue is in nearcore's OpenAPI schema generation.

RpcTransactionResponse uses #[serde(flatten)] with Option<FinalExecutionOutcomeViewEnum>, but schemars doesn't correctly represent that the flattened fields are optional when generating the JSON schema.

So this would require yet another manual workaround 😭

[r-near]

we wanted to replace the near/near-jsonrpc-client-rs with that codebase and release new near-jsonrpc-client-rs crate

I would definitely be open to adopting near-openapi-client into the near org and releasing it as its own crate.

But I'm hesitant to just hot-swap the near-jsonrpc-client-rs codebase, even if we do a major version bump. IMO they're so wildly different. We could "archive" the near-jsonrpc-client-rs repo/crate instead and point people to near-openapi-client once it's stable?

@PolyProgrammist would you be open to transferring the near-openapi-client repo to near?

[frol]

We could "archive" the near-jsonrpc-client-rs repo/crate instead and point people to near-openapi-client once it's stable?

This will create the misalignment in the naming with the clients for other languages. If you want to maintain the old style of manual types, you can keep it in a branch (e.g. call it 0.20.x or 0.x, and release the openAPI-based client as 1.x)

[r-near]

I think where we are at right now, the tooling is just too immature to swap over to these auto-generated clients. IMO there's some foundational work that needs to happen first before we mainline this everywhere. But I'm open to contributing where necessary! I definitely think it's a good end-state!

[frol]

Fair. I’ll move the current repo over to near org