[amberly-d]

Summary

Implements the two deploy-script issues selected for this branch: #1429 (the deprecated stellar contract optimize) and #1430 (retry initialize). All four issues assigned to this account are closed by this PR.

#1429 - replace the deprecated stellar contract optimize

The old flow was two steps:

cargo build --target wasm32-unknown-unknown --release
stellar contract optimize --wasm "$WASM"        # <- deprecated

These are now one supported command:

stellar contract build --optimize

Verified against stellar-cli source (cmd/soroban-cli/src/commands/contract/build.rs):

• --profile defaults to release and the wasm32 target is used, so the artefact lands at the same target/wasm32-unknown-unknown/release/gistpin_contracts.wasm.
• --optimize defaults to true, and the optimiser writes <name>.optimized.wasm then renames it back over <name>.wasm.

So there is no longer a separate .optimized.wasm to read, and the artefact path the script later reads is adjusted accordingly: OPTIMIZED="$WASM".

The deployed WASM is still optimised — it is now simply produced in-place by build --optimize.

#1430 - retry initialize after deploying

A bounded loop (INIT_ATTEMPTS=3, INIT_RETRY_DELAY=10):

• each attempt is preceded by a visible message (==> initialize attempt N/3)
• 10s delay between attempts
• stops after 3 attempts at most
• if all fail, the script exits non-zero with the contract id and moderator address instead of printing Deployment complete for a contract that was never initialised

Validation

shellcheck and bash -n are clean. I could not run a real testnet deploy, so I exercised the entire script end-to-end against stub stellar/cargo/sleep binaries that record behaviour:

Scenario	Result
initialize fails twice, succeeds 3rd	exit 0, exactly 3 attempts, message before each, sleep between
initialize always fails	exit 1, exactly 3 attempts, error: initialize failed after 3 attempts.
initialize succeeds first time	exit 0, 1 attempt
all runs	stellar contract optimize never invoked

Note for maintainers (left unchanged as out of scope for this issue): the prerequisites block still says cargo install --locked stellar-cli --features opt, but current stellar-cli has no opt feature — default = ["additional-libs"] and additional-libs (which is what --optimize needs) is already on by default, so a plain cargo install --locked stellar-cli is what the script now expects.

Closes #1429
Closes #1430
Closes #1431
Closes #1432

[drips-wave]

@amberly-d Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits