#resource_limit_exceeded with a simple transfer

134 messages · Page 1 of 1 (latest)

hushed shadow
#

During my daily round of issues while dapp soroban developement I'm currently getting one that is kind of weird because I'm not really sure what resource I'm hitting.

This tx https://horizon-futurenet.stellar.org/transactions/0bfc5a89920949eccd6a6c774bde168df714736019ba6907f5e6ba28a3b2bf3e is a simple transfer between two accounts using the native asset contract. So the response gives this error:

{
  "fee_charged": 27050,
  "result": {
    "tx_failed": [
      {
        "op_inner": {
          "invoke_host_function": "resource_limit_exceeded"
        }
      }
    ]
  },
  "ext": "v0"
}

From the tx meta I can see this diagnostic event:

"diagnostic_events": [
        {
          "in_successful_contract_call": false,
          "event": {
            "ext": "v0",
            "contract_id": null,
            "type_": "diagnostic",
            "body": {
              "v0": {
                "topics": [
                  {
                    "symbol": "error"
                  },
                  {
                    "error": {
                      "budget": "exceeded_limit"
                    }
                  }
                ],
                "data": {
                  "vec": [
                    {
                      "string": "operation byte-read resources exceeds amount specified"
                    },
                    {
                      "u64": 520
                    },
                    {
                      "u64": 480
                    }
                  ]
                }
              }
            }
          }
        }
      ]

So there it says what the issue is... The problem is that the tx is being build with a simulation from the js sdk so I assume the simulation (and later use of the assembleTransaction method) should take care of setting the correct specified amounts right?

#

Code is this one:

const from: xdr.ScVal = new Address(params.from).toScVal();
const to: xdr.ScVal = new Address(params.to).toScVal();
const amount: xdr.ScVal = nativeToScVal(params.amount, { type: 'i128' });
const tx = new TransactionBuilder(params.sourceAccount, {
    fee: params.fee,
    networkPassphrase: params.networkPassphrase,
    memo: params.memo,
  })
    .setTimeout(params.timeout || 0)
    .addOperation(params.contract.call(params.contractMethod, from, to, amount))
    .build();

  const simulated = await params.server.simulateTransaction(tx);

  if (isSimulationError(simulated)) {
    throw new Error(simulated.error);
  }

  const prepared = assembleTransaction(tx, params.networkPassphrase, simulated).build();

// --- Send and check if ok

EDIT: Here is a runkit link https://runkit.com/earrietadev/649d963bbd73eb0008bba432

#

And if I use prepareTransaction instead of simulating and them assembling it, it gives another diagnostic which is:

"diagnostic_events": [
        {
          "in_successful_contract_call": false,
          "event": {
            "ext": "v0",
            "contract_id": null,
            "type_": "diagnostic",
            "body": {
              "v0": {
                "topics": [
                  {
                    "symbol": "error"
                  },
                  {
                    "error": {
                      "budget": "exceeded_limit"
                    }
                  }
                ],
                "data": {
                  "vec": [
                    {
                      "string": "operation instructions exceeds amount specified"
                    },
                    {
                      "u64": 265388
                    },
                    {
                      "u64": 264978
                    }
                  ]
                }
              }
            }
          }
        }
      ]

The tx for this one is https://horizon-futurenet.stellar.org/transactions/0bfc5a89920949eccd6a6c774bde168df714736019ba6907f5e6ba28a3b2bf3e

still pawn
#

Did you solve it?

hushed shadow
still pawn
#

The contract is the sac right?

hushed shadow
#

Yeah, it's the one for the native asset

still pawn
#

Whats the address for it. Maybe we can make a runkit with this code to try to debug it

#

Im still pretty new on the js dapp side bc im still writing my contracts for the dapp lol but regardless maybe something will stand out

hushed shadow
#

For futurenet it should be this one CB64D3G7SM2RTH6JSGG34DDTFTQ5CFDKVDZJZSODMCX4NJ2HV2KN7OHT

still pawn
#

Thanks

#

Gonna try to make it run

hushed shadow
#

It's an SDK I'm making because I'm tired of writing again and again the tx builders so this SDK is for interacting with the assets from JS... But I don't want to publish it without testing it completely and since yesterday I have been getting weird issues like this one so not sure what it's wrong

still pawn
#

I donno if i see where params.contractmethod is set

#

Ah thats why the code looks foreign to me

hushed shadow
#

params.contractmethod is "transfer" in this case

still pawn
#

How do you build it without simulating dont u need a footprint

#

Yeah i assumed that but

#

Just was sorta curious

#

Whats your code for assembletransaction look like? Is it still using stellar-base

hushed shadow
hushed shadow
still pawn
#

Both fail but different errors?

hushed shadow
#

yeap

still pawn
#

Thanks

#

Did it work on testnet by any chance just to rule out it being some network issue?

#

I dont see how this can exceed limit

hushed shadow
# still pawn Both fail but different errors?

yeah with simulate + assemble it gives: operation byte-read resources exceeds amount specified
While with prepareTransaction it gives: operation instructions exceeds amount specified

still pawn
#

Are you doing other calls first maybe and not resetting the budget

hushed shadow
still pawn
#

Ok

#

I think youve stumped me but it seems like its getting the error in simulate so its not getting a footprint?

#

And theres a way to reset the budget to make it start at zero

hushed shadow
still pawn
#

I think it was fixed i remember reading about that but @void warren could rule that out if hes on

#

Or make another tx manually first to be sure

hushed shadow
still pawn
#

So bc your custom sdk we cant get it on runkit where i can try to see or some way i can step through the code

#

Just confirming understand thst right

hushed shadow
still pawn
#

Is it possible to make it output the transaction envelope and then we can decode it to make sure it looks right

hushed shadow
hushed shadow
# still pawn Is it possible to make it output the transaction envelope and then we can decode...

here is one of them:

AAAAAgAAAACcFZhhHTKAHELgMGtJ+WFHrbUMxHJv+dTB4XTeGBC7KwCZERAACseyAAAAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAGAAAAAAAAAABfcHs35M1GZ/JkY2+DHMs4dEUaqjynMnDYK/Gp0eulN8AAAAIdHJhbnNmZXIAAAADAAAAEgAAAAAAAAAAnBWYYR0ygBxC4DBrSflhR621DMRyb/nUweF03hgQuysAAAASAAAAAAAAAACznoaBSAFU94xNp/h+Br6xhma/8ykc4pgRWq19A5RyZgAAAAoAAAAAAAAAAAAAAAAAmJaAAAAAAQAAAAAAAAAAAAAAAX3B7N+TNRmfyZGNvgxzLOHRFGqo8pzJw2CvxqdHrpTfAAAACHRyYW5zZmVyAAAAAwAAABIAAAAAAAAAAJwVmGEdMoAcQuAwa0n5YUettQzEcm/51MHhdN4YELsrAAAAEgAAAAAAAAAAs56GgUgBVPeMTaf4fga+sYZmv/MpHOKYEVqtfQOUcmYAAAAKAAAAAAAAAAAAAAAAAJiWgAAAAAAAAAABAAAAAAAAAAEAAAAGAAAAAX3B7N+TNRmfyZGNvgxzLOHRFGqo8pzJw2CvxqdHrpTfAAAAFAAAAAEAAAACAAAAAAAAAACcFZhhHTKAHELgMGtJ+WFHrbUMxHJv+dTB4XTeGBC7KwAAAAAAAAAAs56GgUgBVPeMTaf4fga+sYZmv/MpHOKYEVqtfQOUcmYABAsSAAACFAAAAOwAAAAAAAAAOwAAAAEYELsrAAAAQDn4+i8tWrpWZQJ/ra1fbVk0LPutyYkO/IZJ8M8uFgFWRAEND/IcimjfXrbVSsNc0LeNnN8g0ZBsd0aYVJlVgQ0=
still pawn
hushed shadow
#

Here is the other one

AAAAAgAAAACcFZhhHTKAHELgMGtJ+WFHrbUMxHJv+dTB4XTeGBC7KwCZBYsACseyAAAAAQAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAGAAAAAAAAAABfcHs35M1GZ/JkY2+DHMs4dEUaqjynMnDYK/Gp0eulN8AAAAIdHJhbnNmZXIAAAADAAAAEgAAAAAAAAAAnBWYYR0ygBxC4DBrSflhR621DMRyb/nUweF03hgQuysAAAASAAAAAAAAAACznoaBSAFU94xNp/h+Br6xhma/8ykc4pgRWq19A5RyZgAAAAoAAAAAAAAAAAAAAAAAmJaAAAAAAQAAAAAAAAAAAAAAAX3B7N+TNRmfyZGNvgxzLOHRFGqo8pzJw2CvxqdHrpTfAAAACHRyYW5zZmVyAAAAAwAAABIAAAAAAAAAAJwVmGEdMoAcQuAwa0n5YUettQzEcm/51MHhdN4YELsrAAAAEgAAAAAAAAAAs56GgUgBVPeMTaf4fga+sYZmv/MpHOKYEVqtfQOUcmYAAAAKAAAAAAAAAAAAAAAAAJiWgAAAAAAAAAABAAAAAAAAAAEAAAAGAAAAAX3B7N+TNRmfyZGNvgxzLOHRFGqo8pzJw2CvxqdHrpTfAAAAFAAAAAEAAAACAAAAAAAAAACcFZhhHTKAHELgMGtJ+WFHrbUMxHJv+dTB4XTeGBC7KwAAAAAAAAAAs56GgUgBVPeMTaf4fga+sYZmv/MpHOKYEVqtfQOUcmYAA9yyAAAB4AAAALgAAAAAAAAAOwAAAAEYELsrAAAAQN6dSzd6ap90UNZBZUfpe6GEAtyk/ivzvPpWwJirWZRzi6BAOQJQOsIJuHaiuhsEA7bHGyQbbDq2+nMH4WZgUww=
hushed shadow
still pawn
#

Yep

#

But i thought during simulation something

#

Im prob wrong dont worry

#

dHJhbnNmZXI= this is right scval for transfer right

hushed shadow
still pawn
#

instructions: 264978
readBytes: 532
writeBytes: 236
refundableFee: 59

#

Seems within limits here

#

The envelope looks right ya im stumped

#

That fee looks plenty high too

#

I could build the transfer tx and see if we have the same envelope. Obviously without the signature

#

GCZZ5BUBJAAVJ54MJWT7Q7QGX2YYMZV76MURZYUYCFNK27IDSRZGMCCU exists right

#

Wierd problem i bet its something easy we arent thinking of

#

Can we set the timeout to like 5

#

Instead of 0 though i dont think that will be it

hushed shadow
#

I'm making a runkit

still pawn
#

Operation instruction exceed amount specified

265388 264978

And footprint was..264978

#

How do we raise the footprint calculation

hushed shadow
still pawn
#

Its almost like its calculating it wrong in simulation

#

Lol sorru

#

Took me long time to come to the same conclusion u even said first

#

Itts not the timebounds

#

Ill go get on my laptop brb 10 mins

#

Check which version of soroban client u have

hushed shadow
still pawn
#

Does simulation happen via the rpc right?

#

I am training a new llm bot for soroban Hoping it finishes soon this will be a good question for it. But starting to wonder if there is a bug in the code that makes the footprint

#

Makes me wonder now if some of the issues i was having with my contract going over limit could be related to this

#

Could we try a different rpc

#

The simulation happens from host side not the js sdk afaik so its really odd the amount is wrong

#

the host provides an auxiliary "preflight" mechanism that executes a transaction against a temporary, possibly slightly-stale snapshot of the ledger.

#

If the state of the ledger has changed too much between the time of the preflight and the real submission, the footprint may be too stale and no longer accurately identify the keys the transaction needs to read and write, at which point the preflight must be retried to refresh the footprint.

hushed shadow
still pawn
#

Its possibly the issue what i pasted above

#

Okay ill play wit it

#

Im still not on pc sorry bear with me

hushed shadow
still pawn
#

Yes me to

#

I will have to review the host function and its budget calculation we should have a method to increase the preflight budget prediction by a set amount for this type of problem tho

#

But if we think if the bid for the fees goes up

#

Between preflight and submission

#

It could in theory cause the error

#

I assume tho that youve tried just resubmission (rebuild and resubmit)

#

To rule out what im sayin

hushed shadow
still pawn
#

Does the preflight alwys return the same budget prediction or does it vary

#

Im looking through github tryin to find the code in the env for how it works that will help me understand gimme a bit

#

Im always getting status pending but once i got status error. On the runkit but i see no issue at all with this code. The error must be happening from the host side

hushed shadow
#

yeah it's normal that you get status pending, you need to check the tx on the network with the hash later since the RPC doesn't wait until is accepted by the network

still pawn
#

Right. Just makin sure i wasnt messing up.

What is testnets rpc address btw

#

I know u tried that

#

Just for my own knowledge

#

Nvm got it

#

I think i see a hacky fix. But we could maybe intercept and modify the response to inflate the budget in the simulation response

#

Do u have native sac address on testnet too

#
Simulated.cost.cpuInsns = String(Number(Simulated.cost.cpuInsns) * 1.05);
Simulated.cost.memBytes = String(Number(Simulated.cost.memBytes) * 1.05);```
#

Will this do what i want

#

Yes

#

Dunno wtf im tryin to solve it on my phone for but

still pawn
#

Not the best solution

#

But maybe it works? How do i return the tx status to see without having to go manually check

#

No it still failed nvm

#

I see another potential solution but ill have to get on the computer for sure for it

#

That didnt work bc that is modifying the wrong object

#

Basically im thinking to fork this repo and

#

But it still doesnt explain what is going on im not smart enough im sorry

still pawn
still pawn
#

Ok i fixed it

#

But its not elegant

#
simulated.cost.cpuInsns = String(Math.round(Number(simulated.cost.cpuInsns) * 1.05));

simulated.cost.memBytes = String(Math.round(Number(simulated.cost.memBytes) * 1.05));
simulated.minResourceFee = String(Math.round(Number(simulated.minResourceFee) *1.05));

simulated.transactionData._data._attributes.resources._attributes.instructions = Math.round(Number(simulated.transactionData._data._attributes.resources._attributes.instructions) * 1.05);```
@hushed shadow
#

id": "87367a7abe3d96180032f7f068a402f421c7f9d9f6720277928c0b7ad31ab258",
"paging_token": "3042245594845184",
"successful": true,
"hash": "87367a7abe3d96180032f7f068a402f421c7f9d9f6720277928c0b7ad31ab258",
"ledger": 708328,

#

It doesnt explain why the preflight is wrong. You should make a bug report about it in the soroban-tools repo

#

Basically i modified the preflight obj to have 5% higher cost

#

And 5% higher cpu instructions

hushed shadow
#

Got it so it's indeed an issue with the calculation because if we update them then it's ok. I also saw that it's happening with the native asset because I also tried with a created asset and it works

still pawn
#

Ill have to try against my old version of my govenor contract thst kept getting resource limit errors

#

Makes me wonder what is causing it. Gonna clone soroban tools and see if i see an issue on that

dense dune
still pawn
#

It was coming from preflight though i was unable to identify the underlying cause.

hushed shadow
#

@still pawn also shared an example here: #1167924135192694824 message

dense dune
#

I think we need to see what data is being read in both cases. Seems like the data being read is different if the size is different.