feat: added view_receipt_record rpc endpoint

[frolvanya]

Here's an example of calling view_receipt_record:

closes #264

[khorolets]

Nice job indeed! I left a few change requests, but please wait for @kobayurii review before rushing on it. Thank!

[frolvanya]

Thanks for a review! I guess I need to pay more attention to delete all debug leftovers. I've fixed first two issues and I'll wait for @kobayurii review, before pushing changes. However, I still don't know if it's fine to return non Response type from RPC endpoint. Can someone tell me if it's a good practice:

read-rpc/readnode-primitives/src/lib.rs

Lines 180 to 181 in ac8f4f2

	#[derive(serde::Serialize, serde::Deserialize, Debug)]
	pub struct ReceiptRecord {

read-rpc/rpc-server/src/modules/receipts/methods.rs

Lines 39 to 44 in ac8f4f2

	/// Fetches a receipt record by it's ID
	#[cfg_attr(feature = "tracing-instrumentation", tracing::instrument(skip(data)))]
	pub async fn view_receipt_record(
	data: Data<ServerContext>,
	Params(params): Params<serde_json::Value>,
	) -> Result<readnode_primitives::ReceiptRecord, RPCError> {

[kobayurii]

Thank you! Great job! I left a little comment. Also, I noticed that you created a pull request in the main branch. Please reopen the pull request for the develop branch. develop is the main branch for development. Also don't forget to fix the checker.

[khorolets]

However, I still don't know if it's fine to return non Response type from RPC endpoint. Can someone tell me if it's a good practice:

read-rpc/readnode-primitives/src/lib.rs

Lines 180 to 181 in ac8f4f2

	#[derive(serde::Serialize, serde::Deserialize, Debug)]
	pub struct ReceiptRecord {

read-rpc/rpc-server/src/modules/receipts/methods.rs

Lines 39 to 44 in ac8f4f2

	/// Fetches a receipt record by it's ID
	#[cfg_attr(feature = "tracing-instrumentation", tracing::instrument(skip(data)))]
	pub async fn view_receipt_record(
	data: Data<ServerContext>,
	Params(params): Params<serde_json::Value>,
	) -> Result<readnode_primitives::ReceiptRecord, RPCError> {

While it's not perfect either, I would suggest following what @kobayurii did for the other custom method we have here

https://github.com/near/read-rpc/blob/develop/rpc-server/src/modules/state/mod.rs

I am not a fan of duplicating structures, but I would ask you to have the Resuest/Response structures defined in the modules/receipts/mod.rs

Feel free to implement From<ReceiptRecord> or TryFrom for your request/response structures. And drop the serde derives from the original structure.

My thoughts come from the idea of having dedicated structures for (again) request/response. Having From or TryFrom from the internal structure would alert us if we change something in the future.

Thank you for drawing my attention to this question 🙏

[khorolets]

@frolvanya and please update https://github.com/near/read-rpc/blob/main/docs/CUSTOM_RPC_METHODS.md with info about the new method you've added. Thank you.

[frolvanya]

Resuest/Response structures

We need only Response struct, since we can use RpcReceiptRequest as a Request

[khorolets]

Perfect! Thank you 🙏

I've already changed the target branch to develop as @kobayurii requested