Fix expired contract re-deployment

[Julian-dev28]

This issue is based on the the following conversations:
https://stellarfoundation.slack.com/archives/C030Z9EHVQE/p1689620158103189
https://stellarfoundation.slack.com/archives/C030Z9EHVQE/p1689354184687359

What version are you using?

soroban-cli - 0.9.1
soroban sdk - 0.9.2

What did you do?

Encountered an error while attempting to deploy a previously deployed Soroban Token smart contract and the Soroban Hello World smart contract from the soroban examples.

To recreate this event, follow the steps below:

First, clone the soroban-examples repo and navigate to the hello-world directory

git clone https://github.com/stellar/soroban-examples.git
cd soroban-examples/hello_world

Next build the smart contract using the soroban-cli

soroban contract build

Then deploy the contract using soroban-cli

soroban contract deploy \
    --wasm target/wasm32-unknown-unknown/release/soroban_hello_world_contract.wasm \
    --source <SECRET_KEY> \
    --rpc-url https://rpc-futurenet.stellar.org:443 \
    --network-passphrase 'Test SDF Future Network ; October 2022'

What did you expect to see?

The terminal returns the contract address where the contract is deployed:

CAEVCEVHRX73ZTCWJ7XKKDHR72FOASVMQCFBZE7IOHSQ3BBDQNCARNWC

What did you see instead?

An error message with XDR data:

2023-07-17T20:18:45.256152Z ERROR soroban_cli::rpc: response=GetTransactionResponse { status: "FAILED", envelope_xdr: Some("AAAAAgAAAAAR9YTFTa8+n0ZVKMAxeHWx0wLGmd+uZ/B7KPliTXSqUgAAjHUAAMCKAAAAEwAAAAAAAAAAAAAAAQAAAAEAAAAAEfWExU2vPp9GVSjAMXh1sdMCxpnfrmfweyj5Yk10qlIAAAAYAAAAAgAAAhsAYXNtAQAAAAEPA2ACfn4BfmABfgF+YAAAAgcBAXYBRwAAAwMCAQIFAwEAEAYZA38BQYCAwAALfwBBgIDAAAt/AEGAgMAACwcxBQZtZW1vcnkCAAVoZWxsbwABAV8AAgpfX2RhdGFfZW5kAwELX19oZWFwX2Jhc2UDAgrIAQLCAQECfyOAgICAAEEgayIBJICAgIAAAkACQCAAp0H/AXEiAkEORg0AIAJBygBHDQELIAEgADcDCCABQo7o8di6AjcDAEEAIQIDQAJAIAJBEEcNAEEAIQICQANAIAJBEEYNASABQRBqIAJqIAEgAmopAwA3AwAgAkEIaiECDAALCyABQRBqrUIghkIEhEKEgICAIBCAgICAACEAIAFBIGokgICAgAAgAA8LIAFBEGogAmpCAjcDACACQQhqIQIMAAsLAAALAgALAB4RY29udHJhY3RlbnZtZXRhdjAAAAAAAAAAFAAAADMAbw5jb250cmFjdG1ldGF2MAAAAAAAAAAFcnN2ZXIAAAAAAAAGMS43MS4wAAAAAAAAAAAACHJzc2RrdmVyAAAALjAuOS4yI2JmZGRiYzM4MGUyYjIzYzcxMDY5YmQ2MTJiODkxNzc0MDA0MzdhODAAAABDDmNvbnRyYWN0c3BlY3YwAAAAAAAAAAAAAAAFaGVsbG8AAAAAAAABAAAAAAAAAAJ0bwAAAAAAEQAAAAEAAAPqAAAAEQAAAAAAAAAAAQAAAAAAAAAAAAAAAQAAAAd8h5wHnoyd3mug/5MLyMkMiZH0XiFebmBvzGPLm4HVggAAAAAAAWafAAAAKAAAAoAAAAKoAAAAAAAAAIUAAAABTXSqUgAAAEAnZ83tm4aW6P7lR4KKVZ27aHnZF+9YvHjKeE4p+bLtM7Ncyskvmh41PgkNUN1pMsdwTixm4uUfXvdXvfKvGHcO"), result_xdr: Some("AAAAAAAAikP////1AAAAAA=="), result_meta_xdr: Some("AAAAAwAAAAAAAAACAAAAAwAAxiEAAAAAAAAAABH1hMVNrz6fRlUowDF4dbHTAsaZ365n8Hso+WJNdKpSAAAAF0hsiTcAAMCKAAAAEgAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAMAAAAAAADGGwAAAABktaIHAAAAAAAAAAEAAMYhAAAAAAAAAAAR9YTFTa8+n0ZVKMAxeHWx0wLGmd+uZ/B7KPliTXSqUgAAABdIbIk3AADAigAAABMAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAADAAAAAAAAxiEAAAAAZLWiJQAAAAAAAAAAAAAAAgAAAAMAAMYhAAAAAAAAAAAR9YTFTa8+n0ZVKMAxeHWx0wLGmd+uZ/B7KPliTXSqUgAAABdIbIk3AADAigAAABMAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAADAAAAAAAAxiEAAAAAZLWiJQAAAAAAAAABAADGIQAAAAAAAAAAEfWExU2vPp9GVSjAMXh1sdMCxpnfrmfweyj5Yk10qlIAAAAXSGyJvAAAwIoAAAATAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAwAAAAAAAMYhAAAAAGS1oiUAAAAAAAAAAA==") }
error: transaction submission failed: GetTransactionResponse {
    status: "FAILED",
    envelope_xdr: Some(
        "AAAAAgAAAAAR9YTFTa8+n0ZVKMAxeHWx0wLGmd+uZ/B7KPliTXSqUgAAjHUAAMCKAAAAEwAAAAAAAAAAAAAAAQAAAAEAAAAAEfWExU2vPp9GVSjAMXh1sdMCxpnfrmfweyj5Yk10qlIAAAAYAAAAAgAAAhsAYXNtAQAAAAEPA2ACfn4BfmABfgF+YAAAAgcBAXYBRwAAAwMCAQIFAwEAEAYZA38BQYCAwAALfwBBgIDAAAt/AEGAgMAACwcxBQZtZW1vcnkCAAVoZWxsbwABAV8AAgpfX2RhdGFfZW5kAwELX19oZWFwX2Jhc2UDAgrIAQLCAQECfyOAgICAAEEgayIBJICAgIAAAkACQCAAp0H/AXEiAkEORg0AIAJBygBHDQELIAEgADcDCCABQo7o8di6AjcDAEEAIQIDQAJAIAJBEEcNAEEAIQICQANAIAJBEEYNASABQRBqIAJqIAEgAmopAwA3AwAgAkEIaiECDAALCyABQRBqrUIghkIEhEKEgICAIBCAgICAACEAIAFBIGokgICAgAAgAA8LIAFBEGogAmpCAjcDACACQQhqIQIMAAsLAAALAgALAB4RY29udHJhY3RlbnZtZXRhdjAAAAAAAAAAFAAAADMAbw5jb250cmFjdG1ldGF2MAAAAAAAAAAFcnN2ZXIAAAAAAAAGMS43MS4wAAAAAAAAAAAACHJzc2RrdmVyAAAALjAuOS4yI2JmZGRiYzM4MGUyYjIzYzcxMDY5YmQ2MTJiODkxNzc0MDA0MzdhODAAAABDDmNvbnRyYWN0c3BlY3YwAAAAAAAAAAAAAAAFaGVsbG8AAAAAAAABAAAAAAAAAAJ0bwAAAAAAEQAAAAEAAAPqAAAAEQAAAAAAAAAAAQAAAAAAAAAAAAAAAQAAAAd8h5wHnoyd3mug/5MLyMkMiZH0XiFebmBvzGPLm4HVggAAAAAAAWafAAAAKAAAAoAAAAKoAAAAAAAAAIUAAAABTXSqUgAAAEAnZ83tm4aW6P7lR4KKVZ27aHnZF+9YvHjKeE4p+bLtM7Ncyskvmh41PgkNUN1pMsdwTixm4uUfXvdXvfKvGHcO",
    ),
    result_xdr: Some(
        "AAAAAAAAikP////1AAAAAA==",
    ),
    result_meta_xdr: Some(
        "AAAAAwAAAAAAAAACAAAAAwAAxiEAAAAAAAAAABH1hMVNrz6fRlUowDF4dbHTAsaZ365n8Hso+WJNdKpSAAAAF0hsiTcAAMCKAAAAEgAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAMAAAAAAADGGwAAAABktaIHAAAAAAAAAAEAAMYhAAAAAAAAAAAR9YTFTa8+n0ZVKMAxeHWx0wLGmd+uZ/B7KPliTXSqUgAAABdIbIk3AADAigAAABMAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAADAAAAAAAAxiEAAAAAZLWiJQAAAAAAAAAAAAAAAgAAAAMAAMYhAAAAAAAAAAAR9YTFTa8+n0ZVKMAxeHWx0wLGmd+uZ/B7KPliTXSqUgAAABdIbIk3AADAigAAABMAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAADAAAAAAAAxiEAAAAAZLWiJQAAAAAAAAABAADGIQAAAAAAAAAAEfWExU2vPp9GVSjAMXh1sdMCxpnfrmfweyj5Yk10qlIAAAAXSGyJvAAAwIoAAAATAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAwAAAAAAAMYhAAAAAGS1oiUAAAAAAAAAAA==",
    ),
}

[Julian-dev28]

cc @tyvdh @tsachiherman for visibility

[willemneal]

#775 Should help solve this issue. The wasm was already installed and has since expired. So it would need to be restored and bumped as this is a very common contract.

Still having issues with the PR.

[Julian-dev28]

@willemneal
Thanks for the reply. Yeah thats what the team figured as well. Looking forward to the fix!

[tsachiherman]

@Julian-dev28 I'm not sure that this solution solve the core issue here. It does provide an end-user solution, but force the user to go through the error case.

I'd like to propose the following logic -

1. soroban-cli is attempts to deploy a contract.
2. if it succeed, we're done.
3. if it fails due to expiration, a restore operation would be issued instead.
   With the logic above, the end user would be able to call soroban contract deploy knowing that no matter what - the contract would be available once the call is done.

[willemneal]

Exactly, we should be able to recover automatically in both an install and a deploy.

[willemneal]

Relevant ##788

[tsachiherman]

Handle the case for SAC contract data expiration.

[willemneal]

@tsachiherman Spoke at length with Tyler, it seems the main issue is resolved, but rather users have trouble knowing how to restore the contract instance itself.

#789 fixes this by using the contract's instance key if no other keys are provided.

At this point I feel like the bump/restore commands should each become three

1. data
2. instance
3. code

It works currently but would be a little clearer to the user to understand the three options and not have to deal with understanding how to achieve it with flags. Not sure if this should be part of this issue or a new one since it's more of a UX issue.

[kalepail]

I would say let's ship as-is then open another PR we could merge later where we change/add command names

I firmly believe this fix along with the --wasm one that has already been merged are significant enough that we should cut a new official CLI release