fix: ensure account gets funded even if identity already exists

[BlaineHeffron]

Currently if you have an identity saved for an account created locally, whenever your network container resets this account will no longer exist. When we go to generate the account, the generate --fund call to stellar-cli fails with identity already exists. Currently we dont exist on this error because it shouldn't cause the remainder of the code execution to fail. However, if the underlying account no longer exists on-chain, any later commands using that account will fail. So to fix it, I added a keys fund call if we find the identity exists. This ensures the key actually does exist on-chain and is funded. This is only done when the network is not mainnet, and the environment is development or testing.

[BlaineHeffron]

I noticed when changing the fund to within the contract upload error check that the after_deploy script was in the wrong place. It should be within the else statement (if no contract ID is supplied) because it should only be run after actually deploying the contract. You can see in the latest change this was moved to after the deploy call. This fixes after_deploy being run for contracts that have already been deployed and it fixes a potential issue of an account not being funded when it doesn't exist if you have the contract ID already set (all remaining actions are just generating typescript bindings / npm installing none of which require an account).

[pselle]

I like this retry path better, but I'll defer to @willemneal for the final call/what direction this should go.

Also a flag to check out that the after_deploy movement is right -- sounds like it to me.

[pselle]

I tried installing this and testing it end to end. Steps:

• cargo install --path . to install this branch
• created a new project with stellar scaffold init foo
• npm i, cp .env, npm start
• stop stellar container stellar container stop local
• run npm start again (had to do this twice, but I think that was container related and not us)
• Funding does not work:

[0] Account not found, attempting to fund...
[0] 💸 funding "me"
[0] Build error: Failed to parse JSON from http://localhost:8000/friendbot?addr=GCTMOBHGOR4VVJ5KKSLFNGBKRABVYBYSFNG24AAPLBTLIMUQ7MTYSXLN, trailing characters at line 1 column 5```

[pselle]

Fails a test-through

[BlaineHeffron]

The issue is that the friendbot service gets initialized after the rpc server is ready, so there is a race condition with friendbot being ready and the network fund. I fixed it by adding a friendbot status check before continuing after starting the network container.

Here is the output after the fix:

[0] Starting local Stellar Docker container...
[0] ℹ️ Starting local network
[0] ℹ️ Pulling from stellar/quickstart
[0] ℹ️ Digest: sha256:daf5bb1d5de195532ff146339e1968948afefc2d7741bca2393932ebe317315e
[0] ℹ️ Status: Image is up to date for stellar/quickstart:testing
[0] ✅ Started container
[0] 🔎 Watch logs with `stellar network container logs local`
[0] ℹ️ Stop the container with `stellar network container stop local`
[0] Stellar status is not healthy: Object {"error": Object {"code": Number(-32603), "message": String("[-32603] data stores are not initialized: DB is empty")}, "id": Number(1), "jsonrpc": String("2.0")}
[0] Retrying health check.
[0] Stellar RPC is healthy, now checking friendbot...
[0] Friendbot not ready, status: 502 Bad Gateway
[0] Retrying friendbot check.
[0] Friendbot not ready, status: 502 Bad Gateway
[0] Retrying friendbot check.
[0] Friendbot is ready!
[0] Local Stellar network is healthy and running.
<cargo build and other output>
[0] 🔐 creating keys for "me"
[0] An identity with the name 'me' already exists
[0] 📲 installing "soroban_hello_world_contract" wasm bytecode on-chain...
[0] Account not found, attempting to fund...
[0] 💸 funding "me"
[0] ✅ Account AliasOrSecret("me") funded on "Standalone Network ; February 2017"
[0] 🔄 retrying wasm upload...
[0] ℹ️ Simulating install transaction...
[0] ℹ️ Signing transaction: 396024b3a918f5cb8af4a3f5889dff9fb1694326a14e2a5bce34c218ec231036
[0] 🌎 Submitting install transaction...
[0]     ↳ hash: 9bfcbab1c4e9e709b70db7110baf3b3a442781b90eb147fe6bad655b845089bb

[willemneal]

LGTM. Just one question and suggestion