[Access] Invalid GRCP status code returned for transaction with cadence runtime error

[bartolomej]

🐞 Bug Report

FCL-JS documentation mentions that statusCode (on transaction status message) is a standard GRCP core status code: https://grpc.github.io/grpc/core/md_doc_statuscodes.html

But I've seen a transaction result endpoint returning a status code that doesn't match any of the standard status codes (1101):

http localhost:8888/v1/transaction_results/e5f29de24a615190b6dd3e993578494fc4802b558b55c3385bb7e3a69c4815c6
HTTP/1.1 200 OK
Content-Length: 783
Content-Type: application/json; charset=UTF-8
Date: Tue, 20 Jun 2023 12:05:34 GMT
Vary: Origin

{
    "_links": {
        "_self": "/v1/transaction_results/e5f29de24a615190b6dd3e993578494fc4802b558b55c3385bb7e3a69c4815c6"
    },
    "block_id": "3f4e75c0797810171c7451969f13cdf938c6857bbb010da74828ab29460b8042",
    "collection_id": "",
    "computation_used": "0",
    "error_message": "[Error Code: 1101] error caused by: 1 error occurred:\n\t* transaction preprocess failed: [Error Code: 1101] cadence runtime error: Execution failed:\nerror: cannot apply binary operation + to types: `String`, `String`\n --> e5f29de24a615190b6dd3e993578494fc4802b558b55c3385bb7e3a69c4815c6:9:26\n  |\n9 |       let updatedString = currentString + \" Updated\"\n  |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n\n",
    "events": [],
    "execution": "Failure",
    "status": "Sealed",
    "status_code": 1101
}

What is the severity of this bug?

Could have: It really doesn't matter if we do this (product functions without this, impact to user is minimal).

Reproduction steps

Steps to reproduce the behavior:

1. Execute the below transaction which should produce an error

transaction() {
  prepare(signer: AuthAccount) {
    let storedString = signer.load<String>(from: /storage/test)

    if let currentString = storedString {
      // This transaction will fail, because we use a binary "+" operator which doesn't work on strings
      let updatedString = currentString + " Updated"

      signer.save(updatedString, to: /storage/test)
    } else {
      signer.save("New Test", to: /storage/test)
    }
  }
}

2. Retrieve transaction status with /v1/transaction_results/<tx_id>
3. See that status_code = 1101.

Expected behavior

Returned GRCP status codes should have a range of 0-16 and follow the GRCP standard.

Specifications

• Flow emulator v1.2

Additional context

I noticed this while doing maintenance work for Flowser tool in the scope of: onflow/developer-grants#150.

For context, this is impacting just our transaction status UI, which doesn't know how to handle such status (notice the question mark icon):

[bluesign]

hey @bartolomej ,

this is probably an emulator bug, I will check and make a PR.

[bartolomej]

@bluesign Awesome, thanks!

Right, wasn't really sure where this belongs. I just assumed this emulator consumes the flow-go directly, but now I see there is actually an adapter that calls into emulator-specific code, so that does sound more likely indeed!

[peterargue]

There's a bit of confusion here. TransactionResult.StatusCode is actually either 0 or 1, for success or fail:

flow-go/engine/execution/rpc/engine.go

Line 306 in 37ece4c

statusCode = 1 // for now a statusCode of 1 indicates an error and 0 indicates no error

That section of the FCL docs was just talking generally about GRPC status codes, not specifically about this field. Which is confusing since it's immediately after the status field.

"status_code": 1101 is still not correct. That's actually the error code produced by FVM

flow-go/fvm/errors/codes.go

Line 66 in 37ece4c

ErrCodeCadenceRunTimeError ErrorCode = 1101

Looks like @bluesign already as a PR opened to address it.

[bartolomej]

@peterargue Interesting.

That section of the FCL docs was just talking generally about GRPC status codes, not specifically about this field. Which is confusing since it's immediately after the status field.

In that case, I think there may be a mistake in the FCL-JS documentation then because the docs literally links to the GRCP status section for that statusCode field (value type column points to this):

[peterargue]

PR to update the docs: onflow/docs#149

[peterargue]

Closing this issue since I think it was addressed already by a doc update. Feel free to reopen if there's still an issue