#Error: invokeHostFunctionResult: [invokeHostFunctionResourceLimitExceeded]

26 messages · Page 1 of 1 (latest)

void blade
#

I am trying to invoke the auth contract from the soroban examples on futurenet:
https://soroban.stellar.org/docs/how-to-guides/auth

It works well if the invoker is the same as the submitter (
https://soroban.stellar.org/docs/learn/authorization#transaction-invoker) as one can see this transaction: 9fcbe6f8a90f1676b42b245199a7b8040dc4bd2d6e8dbd2e9b85a08a7ddc7e47

But as soon as I try to invoke the contract with a different submitter (tx_submitter != invoker), I am getting not an auth error - but: Error: invokeHostFunctionResult: [invokeHostFunctionResourceLimitExceeded]

This is the transaction hash of the failing transaction:
b171b156392ebb1a17791ba9b47f9e330bb326cec274c41a7483746324c48049

Any idea what may be wrong? Thx

Auth | Soroban - Smart Contracts Platform for Developers

Using the Soroban Host-managed auth framework.

Authorization | Soroban - Smart Contracts Platform for Developers

An overview of the Soroban authorization framework.

latent basalt
#

the new preview contains the new logic for limiting the resource consumption. as you might imagine, this error has nothing to do with auth itself, but with the fact that the resources you supplied with your tx weren't enough to execute it. did you preflight the tx with invoker only?

void blade
void blade
#

If helpful, this is the source code of my test:

$invokerAddress = Address::fromAccountId($invokerId);
$nonce = $server->getNonce($invokerId, $contractId);

$functionName = "increment";
$args = [$invokerAddress->toXdrSCVal(), XdrSCVal::forU32(3)];

$authInvocation = new AuthorizedInvocation($contractId, $functionName, args: $args);

$contractAuth = new ContractAuth($authInvocation, address: $invokerAddress, nonce: $nonce);
$contractAuth->sign($invokerKeyPair, Network::futurenet());

$invokeHostFunction = new InvokeContractHostFunction($contractId, $functionName, $args, auth: [$contractAuth]);

$submitterAccount = $sdk->requestAccount($submitterId);

$builder = new InvokeHostFunctionOperationBuilder();
$op = $builder->addFunction($invokeHostFunction)->build();

$transaction = (new TransactionBuilder($submitterAccount))->addOperation($op)->build();

// simulate first to obtain the transaction data
$simulateResponse = $server->simulateTransaction($transaction);

// set the transaction data + fee and sign
$transaction->setSorobanTransactionData($simulateResponse->getTransactionData());
$transaction->addRessourceFee($simulateResponse->minRessourceFee);
$transaction->sign($submitterKeyPair, Network::futurenet());

// send the transaction
$sendResponse = $server->sendTransaction($transaction);
latent basalt
#

so have you managed to make it succeed?

void blade
#

no 😦

latent basalt
#

the resources are a bit higher indeed as there is one more signature to verify (note, that the difference is pretty marginal in absolute sense)

void blade
#

I did not change anything, unfortunately it is not working with the ressource data from preflight in this case

latent basalt
#

I see. the preflight resource measurement is currently imperfect as it uses recording mode for auth and storage (maybe we need to do an enforcing run... but in any case there are some well-known gaps in consistency). so what I would suggest doing for now is to try increasing the resources and until it succeeds. maybe +20-30% if you don't want to try much

#

(you'll also need to increase the fee as well)

#

FWIW preflight does add some percentage on top of what it measures to account for differences, but apparently that's not enough in this case (not quite certain why though...)

void blade
# latent basalt I see. the preflight resource measurement is currently imperfect as it uses reco...

It works if I increase $transactionData->resources->instructions by 25% and $transactionData->resources->extendedMetaDataSizeBytes by 1:

$transactionData = $simulateResponse->getTransactionData();
$transactionData->resources->instructions += intval($transactionData->resources->instructions / 4);
$transactionData->resources->extendedMetaDataSizeBytes += 1;
$simulateResponse->minRessourceFee += 2800;
#

This is the hash of the successful transaction after increasing the values: 91f6b874259ef35aac6c51afeee160f3aea36125247a289950169c89d5331549

latent basalt
#

I see. FWIW overshooting for metadata is usually a good idea because it's refundable (I don't recall if actual refunds are in preview 9 though). instructions are a bit concerning though, not sure what exactly is up with that...

void blade
#

it works also without increasing the extendedMetaDataSizeBytes. Only instructions must be increased

latent basalt
#

actually we don't meter the signature verification currently in the recording mode (because we don't even have signature during preflight), so probably that's expected

#

this will be addressed eventually

void blade
latent basalt
#

one signature verification is 368361 instructions and your whole invocation is just 1.4M, so numbers seem to add up fine

#

well, preflight does add 10-15% on top of the metered value. probably atomic swap just does more stuff, so +300K instructions would be accounted for in this 10-15% added

void blade
#

yes, it would explain it. Thank you very much Dmytro for helping with this

latent basalt
#

np, sorry for the confusion. resource issues are exactly what we expected with this release

vestal kraken
#

Yes, same error happens to me. By increasing the soroban transaction data it seems to work well...

#

Hey @void bladeI have a question, did you experience any error when you tried to create a contract from the wasm id?

...Because I'm trying to create a contract, but get an invokeHostFunctionTrapped error

void blade