#Factory contract throws scecExceededLimit when deploying new contract

11 messages · Page 1 of 1 (latest)

ashen viper
#

Chain: testnet
Contract address: CB2VTLHEUM4YTSILPJ3S4KKPF7DCL75TWWAYDYEPQMLVUFW4IPJVIZ5X
WASM hash: 4026b2c84d054670aa367aa7c057e591ccb2842117e94b9641eaae11b7af3699
Tx: https://stellar.expert/explorer/testnet/tx/893331722735616
Code:

let state = get_state(e);
let salt = BytesN::from_array(e, &e.prng().gen());
let constructor_args: Vec<Val> = (
    token.clone(),
    merkle_root.clone(),
    caller.clone(),
    vesting_list_hash,
).into_val(e);
let vesting_address = e
    .deployer()
    .with_address(e.current_contract_address(), salt)
    .deploy_v2(state.wasm_hash, constructor_args);
torn kite
#

you are using prng to generate salt. this will result in different contract id during simulation and execution. but we require every entry you access to be present in the footprint. so during simulation you've put a new contract under some address A into footprint, but during the execution you've tried to create a contract under a different address B. so the tx has failed with the "trying to access contract instance outside of the footprint","CCGKDXG6PWQPZP7C423F5PR2JSOMTFGPYXVEKFZM6THXY6UF4XCA2BZF"

#

the way to fix this is to provide salt as an input argument to your contract call. or use completely deterministic salt, depending on what your goals are (e.g. liquidity pools can use a token pair hash as salt)

tired star
#

I ran into this same scenario as above recently where I kept getting the exceeded limit error, and I missed that it was the footprint and was debugging why my resource limts were exceeded.

#

It would be less confusing if accessing outside the footprint used a different error.

torn kite
#

I'm not sure what exactly the comment implies. the logic behind the 'limit exceeded' error is that footprint is a resource that just happens to also account for the set inclusion besides simple counting. I'm not sure what would be a better error code here. I'm also not sure if it makes sense to rely on error codes for diagnostics; we have events that have detailed description of what exactly is wrong. I don't think we will try to make error codes to comprehensively cover each and every scenario that we currently communicate via text in diagnostic events. so I'm not sure how much value is there to put effort into bespoke error codes.

tired star
#

I get that, but this is a case where I've seen how easy it is for the "exceeds limit" error code quickly points a developer in a direction that isn't what they should be looking at. It's fair to not fix that, but it is an undesirable devx.

torn kite
#

I agree that error codes are not perfect and I honestly don't think host error codes are useful for diagnostics most of the time. maybe diagnostic event messages should be highlighted instead of the error codes. maybe it would have been a better idea to not surface the error codes at all, as they inevitable lead to confusion in some way (unless, again, they were very, very granular)

ashen viper
#

thank you @torn kite
I updated the salt to this

let mut salt = Bytes::new(e);      salt.append(&state.vesting_id.to_xdr(e);
salt.append(&token.clone().to_xdr(e));
let salt = e.crypto().sha256(&salt);

and it works. One more question, is it ok to create salt like this?

torn kite
#

I don't know your contract logic and I'm not a security auditor, so I can't provide a definitive answer. my basic understanding is that if you want to have a unique contract instance per vesting_id+token combination, then this code should work as intended. if there is a possibility to have multiple instances per such pair, then this would be not correct.