Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cargo-near extracts wrong ABI in some cases #95

Open
Yoon-Suji opened this issue Dec 8, 2022 · 2 comments
Open

cargo-near extracts wrong ABI in some cases #95

Yoon-Suji opened this issue Dec 8, 2022 · 2 comments

Comments

@Yoon-Suji
Copy link

Hi!
I'm trying to extract the ABI of the near-sdk-rs/examples code using cargo-near. However, it seems that it extracts the wrong ABI in some cases.

When I run cargo-near in examples/cross-contract-call/high-level , the factorial function comes out view function. But it only success when n = 1, and if n>1, the following error occurs:
Error: Querying [object Object] failed: wasm execution failed with error: FunctionCallError(HostError(ProhibitedInView { method_name: "promise_batch_create" })).
It success when I use call.
스크린샷 2022-12-08 오후 7 42 44

cross-contract-high-level-abi.json :

"functions": [
      {
        "name": "factorial",
        "kind": "view",
        "params": {
          "serialization_type": "json",
          "args": [
            {
              "name": "n",
              "type_schema": {
                "type": "integer",
                "format": "uint32",
                "minimum": 0.0
              }
            }
          ]
        },
        "result": {
          "serialization_type": "json",
          "type_schema": {
            "$ref": "#/definitions/PromiseOrValueuint32"
          }
        }
      },

Also in the case of examples/factory-contract/high-level, kind of deploy_status_message and get_result comes out view. However when I execute that method using view, an error occurs as same in the above case. And It works well when I use call.

{
        "name": "deploy_status_message",
        "kind": "view",
        "params": {
          "serialization_type": "json",
          "args": [
            {
              "name": "account_id",
              "type_schema": {
                "$ref": "#/definitions/AccountId"
              }
            },
            {
              "name": "amount",
              "type_schema": {
                "type": "string"
              }
            }
          ]
        }
      },
      {
        "name": "get_result",
        "kind": "view",
        "params": {
          "serialization_type": "json",
          "args": [
            {
              "name": "account_id",
              "type_schema": {
                "$ref": "#/definitions/AccountId"
              }
            }
          ]
        },
        "callbacks": [
          {
            "serialization_type": "json",
            "type_schema": {
              "type": "null"
            }
          }
        ],
        "result": {
          "serialization_type": "json",
          "type_schema": {
            "$ref": "#/definitions/Promise"
          }
        }
      },

I'm not sure but I think that abi is extracted like this in the case of a cross-contract call. Could you check this issue?

@itegulov
Copy link
Contributor

itegulov commented Dec 9, 2022

This is a part of a bigger problem where near-sdk-rs decides whether a function is call or view purely based on how self is borrowed. In this case, factorial borrows &self, which indicates that this is a view function. This is obviously false though as the function makes a cross-contract call. We could add an ad-hoc case where we check the return and mark functions as call if the return type is Promise.

The long-term fix would probably have to be explicit #[call]/#[view] annotations for all functions.

CC @miraclx @austinabell

@Yoon-Suji
Copy link
Author

@itegulov
Oh, I see. Thank you for your answer!
And also I wonder when this issue can be resolved👀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants