Substrate Upgrade v1.0.0 Known Issues

[surangap]

KIS-01 - Transfer Transactions

If you products use assets.transferKeepAlive(), balances.transferKeepAlive() and assetsExt.transfer(,,true) please be aware that the transactions will fail if the transfer amount is equal to the free balance when query assets.account and system.account

Recommendation: switch to use assets.transfer, balances.transfer or assetsExt.transfer(,,false) to allow total amount is transferred, with acceptance that account will be reaped from the corresponding pallet.

Reaped accounts are accounts that have their references removed from the pallet where the transfer happened, e.g assets or balances. Reaped accounts will be re-activated again when there are transfers coming to them. It’s a low level garbage collection mechanism, which should not affect end-users.

KIS-03 - CLI Flags

Several CLI flags have been renamed

• --ws-port to --rpc-port
• --ws-max-connections to --rpc-max-connections
• --unsafe-ws-external to --unsafe-rpc-external

KIS-04 - ROOT Balance Query

The system.account storage has changed it’s structure.
Current structure

{
  nonce: 0
  consumers: 2
  providers: 1
  sufficients: 5
  data: {
    free: 27,087,224
    reserved: 652
    miscFrozen: 27,000,000
    feeFrozen: 27,000,000
  }
}

New structure

{
  nonce: 0
  consumers: 2
  providers: 1
  sufficients: 5
  data: {
    free: 27,087,224
    reserved: 652
    frozen: 27,000,000
    flags: 170,141,183,460,469,231,731,687,303,715,911,105,728
  }
}

miscFrozen and feeFrozen have been replaced with a single frozen field.

To calculate a spendable amount, use the the following algorithm

spendable = free + reserved - frozen

Alternatively, if you just want to check the current balance of an account use api.rpc.assetsExt.freeBalance(address) call

⚠️ NOTE: This only apply to ROOT token

KIS-05 - Telemetry connection failure

With the new substrate node there might be a scenario where the telemetry never gets connected with the following error.

Error while dialing /dns/telemetry.rootnet.app/tcp/9443/x-parity-wss/%2Fsubmit: Custom { kind: Other, error: Timeout }    

This might not happen depending on the infrastructure where the nodes are running. mainly if you are running inside kubernetes, this is due to a DNS resolver config issue.
Please use the absolute url for telemetry if this happens.

--telemetry-url="wss://telemetry.rootnet.app.:9443/submit 0"

TRN docs will be updated to reflect the change.

[olexiyb]

We have upgraded 3 porchini pods on prod cluster and 3 porchini pods
So far everything running fine
The only problem I see

Error while dialing /dns/telemetry.rootnet.app/tcp/9443/x-parity-wss/%2Fsubmit: Custom { kind: Other, error: Timeout }    

Here are perameters we use

      containers:
        - args:
            - --rpc-max-response-size=15
            - --max-runtime-instances=8
            - --rpc-max-connections=256
            - --runtime-cache-size=64
            - '--state-pruning=archive'
            - '--blocks-pruning=archive'
            - '--sync=full'
            - '--name=rootscan-prod-scd1'
            - '--chain=porcini'
            - --rpc-external
            - --rpc-cors=all
            - '--telemetry-url'
            - 'wss://telemetry.rootnet.app:9443/submit 0'
          image: ghcr.io/futureversecom/seed:8.55.0

[surangap]

We have upgraded 3 porchini pods on prod cluster and 3 porchini pods So far everything running fine The only problem I see

Error while dialing /dns/telemetry.rootnet.app/tcp/9443/x-parity-wss/%2Fsubmit: Custom { kind: Other, error: Timeout }    

Here are perameters we use

      containers:
        - args:
            - --rpc-max-response-size=15
            - --max-runtime-instances=8
            - --rpc-max-connections=256
            - --runtime-cache-size=64
            - '--state-pruning=archive'
            - '--blocks-pruning=archive'
            - '--sync=full'
            - '--name=rootscan-prod-scd1'
            - '--chain=porcini'
            - --rpc-external
            - --rpc-cors=all
            - '--telemetry-url'
            - 'wss://telemetry.rootnet.app:9443/submit 0'
          image: ghcr.io/futureversecom/seed:8.55.0

@olexiyb Thank you for letting us know. Added KIS-05 above with a fix for this.

[olexiyb]

@surangap I am confused with your point
I already have --telemetry-url=wss://telemetry.rootnet.app:9443/submit 0
So you say that I have missing . and it should be --telemetry-url=wss://telemetry.rootnet.app.:9443/submit 0

[surangap]

@surangap I am confused with your point I already have --telemetry-url=wss://telemetry.rootnet.app:9443/submit 0 So you say that I have missing . and it should be --telemetry-url=wss://telemetry.rootnet.app.:9443/submit 0

@olexiyb Yes, that's correct. that extra trailing. will make it absolute and stop going for the DNS resolver search paths.

[olexiyb]

I still see an error

Error while dialing /dns/telemetry.rootnet.app./tcp/9443/x-parity-wss/%2Fsubmit: Custom { kind: Other, error: Timeout }