Node add stops working when you run account init before

[jeromy-cannon]

The network consensus nodes are configured to use a specific account ID to do the freeze transaction. Currently, Solo is using the treasury account 0.0.2. It needs to be updated to use the default freeze transaction account 0.0.58.

To recreate the issue:

  SOLO_CLUSTER_NAME=solo-e2e
  SOLO_NAMESPACE=solo-e2e
  SOLO_CLUSTER_SETUP_NAMESPACE=solo-e2e-cluster
  FST_CHARTS_DIR=~/source/full-stack-testing/charts
  kind delete cluster -n "${SOLO_CLUSTER_NAME}" || true
  kind create cluster -n "${SOLO_CLUSTER_NAME}" || return
  solo init -d ${FST_CHARTS_DIR} --namespace "${SOLO_NAMESPACE}" -i node0,node1,node2 -t v0.47.0 -s "${SOLO_CLUSTER_SETUP_NAMESPACE}" || return
  solo node keys --gossip-keys --tls-keys --key-format pem || return
  solo cluster setup  || return
  solo network deploy || return
  solo node setup || return
  solo node start || return
  solo account init || return
  solo node add -i node3 || return

[JeffreyDallas]

Have this node add feature ever worked ?
To my understanding, to adding new node to the network needs the following steps:

1. update config.txt
2. generate a upgrade package and update the special file 0.0.150
3. send PrepPare upgrade transaction
4. send FreezeUpgrade
5. wait nodes freeze and restart nodes

In current node.mjs implementation, I did not any logic of step 2.

[jeromy-cannon]

yes, that is technically not needed. we instead update the config file version, which is another way to trigger the upgrade per Michael Tinker.

This works normally because we don't run solo account init, so all accounts are using genesis key. But, when you run solo account init, each account gets its own key, and the check to validate that the correct account is running the freeze fails.

[JeffreyDallas]

With latest code on main branch,
the above commands no longer fail at waiting for freeze,
but failed at last step solo node add -i node3
while node3 stuck at OBSERVING status

swirlds.log

[JeffreyDallas]

Get some hint from Austin, we need to also update version number during the upgrade test

[jeromy-cannon]

we already update the version number in the application.properties as part of the node add.

[JeffreyDallas]

After testing with hedera release v0.50.0,
I got the same SignedStateInvalidException as discussed in slack

[jeromy-cannon]

where are you at on this? do you need any help or clarification? are you able to recreate the issue?

[JeffreyDallas]

I believe it is facing the issue you have with #349.

[jeromy-cannon]

if you use v0.49.0-alpha.2, the issue shouldn't exist.