0

It is developing code for sending transaction on the mainnet using stellar-sdk. A tx_not_supported error occurs during submitTransaction(). The network upgrade command(stellar-core http-command 'upgrades?mode=set&upgradetime=2018-01-31T20:00:00Z&protocolversion=15' ) was issued, but the error was not resolved. How can I solve the problem?

If you need additional information, please request it through comments. Thank you.

[source]


// This is the end without errors. oTransaction is also.
...

try {
        const transactionResult = await oServer.submitTransaction(oTransaction)
        console.log(JSON.stringify(transactionResult, null, 2))
        console.log(`\nSuccess! View the transaction at: `)
        callback(null, transactionResult.hash) // txid

    } catch (err) {
        console.log(err.response.data.extras.result_code) // { transaction: 'tx_not_supported' }
        callback(err)
        console.log(`An error has occured.`)
    }

[used version]

  • stellar-core: v15.1.0
  • horizon: v2.0.0
  • captive-core: running
  • protocol version: 15
  • stellar-sdk: v8.0.0 (latest)

These are additional information as Justin Rice's request. Thanks.

[envelopeTypeTx]

Stellar Laborartory links:

https://laboratory.stellar.org/#txsubmitter?input=AAAAAgAAAAA6Do45GTSz6H5%2BV99%2FMSE2und%2B0vdGVp%2Fd6FZ4l0fiAgABhqABAgADAAABHgAAAAEAAAAAAAAAAAAAAABgWTkJAAAAAAAAAAEAAAAAAAAAAAAAAAAyjg161xoXOLvvAOKmsgtLP19%2F%2B7%2Fu3nrr%2Fwlrms%2B%2FkQAAAAABMS0AAAAAAAAAAAGXR%2BICAAAAQKes5dxUhsPZejrSDhZnWahUC8apgjmmy7Cm9QB8HZZobf8jdPbow59GIlfuzcoIRQPgxsyyAd3V6yP0YT9lBQ0%3D&network=public

[ERROR Response]

{   
    type: 'https: //stellar.org/horizon-errors/transaction_failed,  
    title: 'Transaction Failed',  
    status: 400,  
    detail: 'The transaction failed when submitted to the stellar network. The `extras.result_codes` field on this response contains further details.  Descriptions of each code can be found at: https: //www.stellar.org/developers/guides/concepts/list-of-operations.html',  
    extras: 
    { 
        envelope_xdr: 'AAAAAgAAAAA6Do45GTSz6H5+V99/MSE2und+0vdGVp/d6FZ4l0fiAgABhqABAgADAAABHgAAAAEAAAAAAAAAAAAAAABgWTkJAAAAAAAAAAEAAAAAAAAAAAAAAAAyjg161xoXOLvvAOKmsgtLP19/+7/u3nrr/wlrms+/kQAAAAABMS0AAAAAAAAAAAGXR+ICAAAAQKes5dxUhsPZejrSDhZnWahUC8apgjmmy7Cm9QB8HZZobf8jdPbow59GIlfuzcoIRQPgxsyyAd3V6yP0YT9lBQ0=',  
        result_codes: 
        { 
            transaction: 'tx_not_supported'
        }
    }
}

Here are the setting files. (stellar-core.cfg, stellar-captive-core-stub.toml) as you request @Bartek Nowotarski

[stellar-core.cfg]
LOG_FILE_PATH="/home/stellar/logs/stellar-core.log"
BUCKET_DIR_PATH="/home/stellar/buckets" 

HTTP_PORT=8080
PUBLIC_HTTP_PORT=true
PEER_PORT=11625

DATABASE="postgresql://dbname=stellar host=localhost user=stellar password=XXX"

#FAILURE_SAFETY is minimum number of nodes that are allowed to fail before you no longer have quorum
FAILURE_SAFETY=1

# number of ledgers to synchronize (time in seconds divided by 5)
# NB: full validators should run with CATCHUP_COMPLETE=true instead
CATCHUP_COMPLETE=true 
#CATCHUP_RECENT=60480

NETWORK_PASSPHRASE="Public Global Stellar Network ; September 2015"

TARGET_PEER_CONNECTIONS=16 

# Populate NODE_NAMES, KNOW_PEERS, QUORUM and HISTORY sections with information
# on other validators
# for example https://github.com/stellar/docs/blob/master/validators.md
# or from https://dashboard.stellar.org/
NODE_NAMES=[
"GCGB2S2KGYARPVIA37HYZXVRM2YZUEXA6S33ZU5BUDC6THSB62LZSTYH  sdf_watcher1",
"GCM6QMP3DLRPTAZW2UZPCPX2LF3SXWXKPMP3GKFZBDSF3QZGV2G5QSTK  sdf_watcher2",
"GABMKJM6I25XI4K7U6XWMULOUQIQ27BCTMLS6BYYSOWKTBUXVRJSXHYQ  sdf_watcher3",
]

KNOWN_PEERS=[
"core-live-a.stellar.org",
"core-live-b.stellar.org",
"core-live-c.stellar.org",
]

UNSAFE_QUORUM=true

[QUORUM_SET]
THRESHOLD_PERCENT=51
VALIDATORS=[
"$sdf_watcher1", "$sdf_watcher2", "$sdf_watcher3"
]

# Stellar.org history store
[HISTORY.core_live_001]
get="curl -sf http://history.stellar.org/prd/core-live/core_live_001/{0} -o {1}"

[HISTORY.core_live_002]
get="curl -sf http://history.stellar.org/prd/core-live/core_live_002/{0} -o {1}"

[HISTORY.core_live_003]
get="curl -sf http://history.stellar.org/prd/core-live/core_live_003/{0} -o {1}"


[stellar-captive-core-stub.toml]

[[HOME_DOMAINS]]
HOME_DOMAIN="www.stellar.org"
QUALITY="HIGH"

[[VALIDATORS]]
NAME="sdf_1"
HOME_DOMAIN="www.stellar.org"
PUBLIC_KEY="GCGB2S2KGYARPVIA37HYZXVRM2YZUEXA6S33ZU5BUDC6THSB62LZSTYH"
ADDRESS="core-live-a.stellar.org"
HISTORY="curl -sf http://history.stellar.org/prd/core-live/core_live_001/{0} -o {1}"

[[VALIDATORS]]
NAME="sdf_2"
HOME_DOMAIN="www.stellar.org"
PUBLIC_KEY="GCM6QMP3DLRPTAZW2UZPCPX2LF3SXWXKPMP3GKFZBDSF3QZGV2G5QSTK"
ADDRESS="core-live-b.stellar.org"
HISTORY="curl -sf http://history.stellar.org/prd/core-live/core_live_002/{0} -o {1}"

[[VALIDATORS]]
NAME="sdf_3"
HOME_DOMAIN="www.stellar.org"
PUBLIC_KEY="GABMKJM6I25XI4K7U6XWMULOUQIQ27BCTMLS6BYYSOWKTBUXVRJSXHYQ"
ADDRESS="core-live-c.stellar.org"
HISTORY="curl -sf http://history.stellar.org/prd/core-live/core_live_003/{0} -o {1}"
2
  • You mention that it's mainnet code so in such case you wouldn't need to upgrade the protocol manual. Can you share your config (without exposing any secrets)? – Bartek Nowotarski Mar 24 at 12:52
  • The config is added now. Please take a look that. Thanks :D – Boohyung Lee Mar 25 at 0:05
0

I think this is what's happening: in your Captive Core config, you specified CATCHUP_COMPLETE=true. As a result, your Captive Core node is likely still catching up to the network (see Joining the Network). While it is in that state, your node is still technically at the genesis ledger (the very beginning of the network), so its protocol version is 0.

I believe you will continue to get this error for as long as your node is catching up. If you do not need to query the entire history of the network, you should use CATCHUP_RECENT instead of CATCHUP_COMPLETE.

If you do want your Horizon node to ingest the full history of the network, instead of using CATCHUP_COMPLETE, you can instead use the new Horizon architecture to ingest the history from archives. Because you can parallelize archive ingestion across multiple workers, the ingestion process, which used to take weeks, can be done in ~1.5 days.

For a complete guide on how to ingest from archives, see: https://github.com/stellar/go/blob/master/services/horizon/internal/docs/captive_core.md#using-captive-core-to-reingest-the-full-public-network-history

4
  • In my question, I added XDR data(base-64 encoded TransactionEnvelope) and complete JSON error response. Please take a look and forward your team. Thanks. – Boohyung Lee Mar 23 at 1:05
  • I don't know why Captive Core(Stellar-core) config value is cause, especially, "CATCHUP_COMPLETE, CATCHUP_RECENT". On the testnet, I have tried sending transaction(type: create_account). and have checked successful transaction. (testnet.stellarchain.io/tx/…) – Boohyung Lee Apr 2 at 1:33
  • While your node is in the "Catchup up" stage, it is still technically at the genesis ledger, which has a protocol number of 0, so it doesn't support this current form of transaction. When it is done catching up, it will be in the "synced" stage, at which point you node will be on Protocol 15, which does support this kind of transaction. The testnet node you are using, on the other hand, is already in the "synced" stage, so it doesn't run into the same problem. – Justin Rice Apr 2 at 10:08
  • One other note: if you want a Horizon node with the full history of the ledger, you can use the new Horizon architecture to ingest that history from archives rather than using CATCHUP_COMPLETE. Doing so can reduce the time it takes to ingest the full history to ~1.5 days. See: github.com/stellar/go/blob/master/services/horizon/internal/… – Justin Rice Apr 2 at 11:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.