Initial call to a SAC method fails. Subsequent calls succeed

[zealous slate]

I recall a report of a known bug with the SAC that when a new address is interacting with an existing sac for the first time it returns a FAILURE on submission but subsequent calls will SUCCESS. Was this not fixed? I'm still facing it. At least in a local quickstart.

[jolly hornet]

I don't recall this being a SAC bug - IIRC it had something to do with fees for the rent bumps and I think this has been addressed. basically, we need more details on repro

(and at least more details on the errors)

[zealous slate]

👍 will try and get a basic reproducible example soon(ish)

[thorny anvil]

Chiming in on this - I may be coming across a related issue in which calls to an SAC via the JS soroban client will fail if the SAC has been inactive for long enough, but calls via the the CLI will succeed (and subsequent calls via JS will also succeed).

I was thinking that I could just periodically bump the SAC but there seems to be some issues with that

[jolly hornet]

it probably has been moved to the 'expired' state ('archived' if we use the new terminology). though it could be that you're actually looking up non-existent key...

[thorny anvil]

The strange thing is that if I just call it via the CLI, it works anyway

... and after calling it, the bump works as intended

[jolly hornet]

hmm, need to check the CLI code - maybe it restores entries automatically?

and if not, then something is definitely wrong...

[thorny anvil]

You're right, the CLI's implementation includes the thing where a restore transaction is sent first when the preflight has a restore_preamble https://github.com/stellar/soroban-tools/blob/2b5bb4f8a6f1a8ab5ccc23b6633b38036411636f/cmd/soroban-cli/src/rpc/mod.rs#L683

[jolly hornet]

so the most likely explanation is that entry has expired and we don't allow bumping expired entries. that said, probably it's worth to impelement the same flow for all the CLI ops (i.e. if entry can be restored, restore it first), otherwise we have this confusing behavior.

would you mind opening an issue for soroban-tools repo describing this inconsistency?

[thorny anvil]

Will do. 🫡

Also, what are your thoughts on having this behaviour also be consistent in the javascript SDK?

[jolly hornet]

CLI is somewhat more straightforward because it's a developer tool and you're the only one paying the fees. in case of JS it's not clear if your dapp should restore entries by default at user cost (e.g. imagine the user needs to sign the restoration operation - that might be confusing). so I'd say this could be an option - definitely useful to have, but not something that should always be on by default

[thorny anvil]

Good point, I forgot that it would result in two signing prompts if the user was using a wallet app

[thorny anvil]

@silent temple lemme redirect you here from #🔹｜developer-chat message

It's possible to build a contract restoration operation on the frontend, but I'm not sure if it's a good idea to have the user pay for the cost of that transaction.

[silent temple]

Why do you want me to redirect here?
The problem we disussed is different from this problem

[thorny anvil]

dmytro's message is a good summary of the difference between restoring the token on the CLI side and restoring it on the frontend side