Component

• 1: SOLO-3001
• 2: SOLO-3003
• 3: SOLO-3004
• 4: SOLO-3005
• 5: SOLO-3006
• 6: SOLO-3007
• 7: SOLO-3008
• 8: SOLO-3009
• 9: SOLO-3010
• 10: SOLO-3011
• 11: SOLO-3012
• 12: SOLO-3013
• 13: SOLO-3014
• 14: SOLO-3015
• 15: SOLO-3016
• 16: SOLO-3017
• 17: SOLO-3018
• 18: SOLO-3019
• 19: SOLO-3021
• 20: SOLO-3022
• 21: SOLO-3023
• 22: SOLO-3024
• 23: SOLO-3025
• 24: SOLO-3026
• 25: SOLO-3027
• 26: SOLO-3028
• 27: SOLO-3029
• 28: SOLO-3030
• 29: SOLO-3031
• 30: SOLO-3032
• 31: SOLO-3033
• 32: SOLO-3034
• 33: SOLO-3035
• 34: SOLO-3036
• 35: SOLO-3037
• 36: SOLO-3038
• 37: SOLO-3039
• 38: SOLO-3040
• 39: SOLO-3041
• 40: SOLO-3042
• 41: SOLO-3043
• 42: SOLO-3044
• 43: SOLO-3045
• 44: SOLO-3046
• 45: SOLO-3047
• 46: SOLO-3048
• 47: SOLO-3049
• 48: SOLO-3050
• 49: SOLO-3051
• 50: SOLO-3052
• 51: SOLO-3053
• 52: SOLO-3054
• 53: SOLO-3055
• 54: SOLO-3056
• 55: SOLO-3057
• 56: SOLO-3058
• 57: SOLO-3059
• 58: SOLO-3060
• 59: SOLO-3061
• 60: SOLO-3062
• 61: SOLO-3063
• 62: SOLO-3064
• 63: SOLO-3065
• 64: SOLO-3066
• 65: SOLO-3067
• 66: SOLO-3068
• 67: SOLO-3069
• 68: SOLO-3070
• 69: SOLO-3071
• 70: SOLO-3072
• 71: SOLO-3073
• 72: SOLO-3074
• 73: SOLO-3075
• 74: SOLO-3076
• 75: SOLO-3077
• 76: SOLO-3078
• 77: SOLO-3079
• 78: SOLO-3080
• 79: SOLO-3081
• 80: SOLO-3082
• 81: SOLO-3083
• 82: SOLO-3084
• 83: SOLO-3085
• 84: SOLO-3086
• 85: SOLO-3087
• 86: SOLO-3088
• 87: SOLO-3089

1 - SOLO-3001

NodeTransactionFailedSoloError

Description

Thrown when a Hedera SDK transaction that solo submitted to a consensus node receives a receipt whose status is not SUCCESS. The error message carries the operation that failed and the raw network status code (for example node create transaction failed with status: INVALID_SIGNATURE). This means the network reached and rejected the transaction rather than failing to deliver it: common causes are a node that has not yet reached ACTIVE during setup, staking, or a network upgrade; an operator/admin key that does not match the account; or an address-book/state precondition that the transaction violated. The specific status code identifies which.

Troubleshooting Steps

1. Check the solo logs for details: tail -n 100 ~/.solo/logs/solo.log
2. Verify the node pod is running: kubectl get pods -n -l solo.hedera.com/type=network-node
3. Consult the Hedera documentation for the meaning of the status code

2 - SOLO-3003

NodeBuildUploadFailedSoloError

Description

Thrown when solo cannot upload the build.zip artifact; the underlying failure is wrapped in cause. solo uploads the packaged build so nodes can be provisioned from it, so this means the upload failed — for example the source file was missing or unreadable, or the destination was unreachable. It is retryable.

Troubleshooting Steps

1. Review solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Check node pod status: kubectl get pods -n -l solo.hedera.com/type=network-node
3. Inspect the pod for more detail: kubectl describe pod -n

3 - SOLO-3004

NodeBuildCopyFailedSoloError

Description

Thrown when solo cannot copy a local build into a consensus node; the underlying failure is wrapped in cause. When running with a local platform build, solo copies the build artifacts into the node pod, so this means that copy failed — for example the pod was not reachable, the destination path was not writable, or the connection dropped mid-copy. It is retryable.

Troubleshooting Steps

1. Check pod status: kubectl get pods -n -l solo.hedera.com/type=network-node
2. Verify the local build path is valid and readable
3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

4 - SOLO-3005

NodeJfrExecutionFailedSoloError

Description

Thrown when a Java Flight Recorder (JFR) operation on a consensus node pod fails; the message names the operation and the pod. solo runs JFR commands inside the node container to capture profiling data, so this means that command failed — for example the pod was not reachable or the command returned an error. It is retryable.

Troubleshooting Steps

1. Check if the node pod is running: kubectl get pod -n
2. Verify the pod has jcmd available: kubectl exec -n – which jcmd
3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

5 - SOLO-3006

NodeJfrPidNotFoundSoloError

Description

Thrown when solo cannot find the ServicesMain process id inside a consensus node pod; the message names the pod. JFR profiling must attach to the running node process, so this is raised when that process cannot be located — which points to an unexpected container state or a defect in how solo locates the process, and is treated as an internal Solo error.

Troubleshooting Steps

1. Verify the consensus node is running inside the pod: kubectl exec – ps axww -o pid,command
2. Check node startup logs: kubectl logs -n
3. Restart the node if ServicesMain is absent: solo consensus node restart

6 - SOLO-3007

NodeDebugArchiveFailedSoloError

Description

Thrown when solo cannot create the debug archive it assembles for troubleshooting; the underlying failure is wrapped in cause. The archive bundles a node’s logs and diagnostic data, and reaching this failure points to a problem in solo’s archive-creation logic rather than user or infrastructure input, so it is treated as an internal Solo error and should be reported with the full error output.

Troubleshooting Steps

1. Verify the output directory is writable
2. Check available disk space: df -h
3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

7 - SOLO-3008

BlockNodeConfigFailedSoloError

Description

Thrown when solo fails while building the block-nodes configuration; the underlying failure is wrapped in cause. solo generates the configuration that tells consensus nodes how to reach the block nodes, so this means that generation step failed — for example required connection details could not be resolved. It is retryable, since a transient resolution problem often clears on a later attempt.

Troubleshooting Steps

1. Check block node pod status: kubectl get pods -n -l block-node.hiero.com/type=block-node
2. Check network node pod status: kubectl get pods -n -l solo.hedera.com/type=network-node
3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log
4. Verify the cluster is reachable: kubectl cluster-info –context

8 - SOLO-3009

ChartInstallFailedSoloError

Description

Thrown when solo cannot install a Helm chart; the message names the chart and wraps the underlying failure in cause. solo installs charts to deploy its components, so this means the Helm install failed — for example a bad chart version or values, an image that cannot be pulled, or a cluster that is unreachable or short on resources. It is retryable, since transient registry or cluster issues often clear on a later attempt.

Troubleshooting Steps

1. Check Helm release status: helm list -n
2. Review Helm errors: helm status -n
3. Verify the cluster is reachable: kubectl cluster-info –context
4. Retry after inspecting solo logs: tail -n 100 ~/.solo/logs/solo.log

9 - SOLO-3010

NetworkDestroyFailedSoloError

Description

Thrown when solo consensus network destroy cannot tear down the consensus network; the underlying failure is wrapped in cause. Destroy uninstalls the network Helm release and removes its consensus node pods and resources, so this means teardown did not complete — for example a Helm release could not be removed or the cluster API was unreachable.

Troubleshooting Steps

1. Check remaining Helm releases: helm list -A
2. Check for stuck namespaces: kubectl get namespaces
3. Manually clean up: helm uninstall -n
4. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

10 - SOLO-3011

NodeNotReadySoloError

Description

Thrown when a consensus node does not reach the expected status within the allotted polling attempts; the message names the node alias, the expected status, and the attempt count (attempt/maxAttempts). solo polls node status while waiting for nodes to come up or change state, and raises this once the attempts are exhausted without the node reaching the expected status — for example the node is crash-looping, stuck during startup, or unable to join the network.

Troubleshooting Steps

1. Check node pod status: kubectl get pods -n -l solo.hedera.com/node-name=
2. View node logs: kubectl logs -n -l solo.hedera.com/node-name=
3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

11 - SOLO-3012

RapidFireExecutionSoloError

Description

Thrown when a rapid-fire load test step fails to execute; the message describes the failing step and, when present, wraps the underlying cause. Rapid-fire runs load against the network, so this means one of its execution steps did not succeed. It is retryable, since transient cluster or network issues during the test often clear on a later attempt.

Troubleshooting Steps

1. Check NLG pod logs for TPS output and errors: kubectl logs -n -l app.kubernetes.io/instance=network-load-generator
2. Retry with lower load parameters or a reduced –max-tps value

12 - SOLO-3013

NodeStakeTransactionErrorSoloError

Description

Thrown when a staking transaction fails to execute; when available the underlying failure is wrapped in cause. solo submits staking transactions to configure how accounts and nodes stake, so this means the transaction was rejected or could not be submitted. It is retryable, since a transient network or node-readiness issue often clears on a later attempt.

Troubleshooting Steps

1. Verify the treasury account has sufficient HBAR balance.
2. Confirm the node is in ACTIVE status: kubectl get pods -n -l solo.hedera.com/type=network-node
3. Check gRPC connectivity to the consensus node.
4. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

13 - SOLO-3014

NodePrepareUpgradeTransactionErrorSoloError

Description

Thrown when the prepare-upgrade transaction fails to execute; when available the underlying failure is wrapped in cause. This transaction stages the upgrade artifacts on the network before a freeze-upgrade, so this means staging was rejected or could not be submitted — for example the upgrade file was not present or valid, or the network could not be reached. It is retryable.

Troubleshooting Steps

1. Verify the node admin key is correct and loaded from the k8s secret.
2. Confirm the freeze admin account has sufficient HBAR balance.
3. Verify the upgrade zip file hash is correct.
4. Check node client connection to the consensus network.
5. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

14 - SOLO-3015

NodeFreezeUpgradeTransactionErrorSoloError

Description

Thrown when a freeze-upgrade transaction fails to execute; when available the underlying failure is wrapped in cause. solo submits this transaction to freeze the network in preparation for a software upgrade, so this means it was rejected or could not be submitted — for example the prepared upgrade was not staged, the admin key did not sign, or the network could not be reached. It is retryable.

Troubleshooting Steps

1. Verify the node admin key is correct and loaded from the k8s secret.
2. Confirm the freeze admin account has sufficient HBAR balance.
3. Verify the nodes have completed the prepare upgrade step.
4. Verify gossip endpoints and gRPC service endpoints are reachable from the network.
5. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

15 - SOLO-3016

NodeFreezeTransactionErrorSoloError

Description

Thrown when a freeze-only transaction fails to execute; when available the underlying failure is wrapped in cause. solo submits a freeze-only transaction to pause the network (for example before maintenance), so this means the transaction was rejected or could not be submitted. It is retryable, since a transient network or node-readiness problem often clears on a later attempt.

Troubleshooting Steps

1. Verify the node admin key is correct and loaded from the k8s secret.
2. Confirm the freeze admin account has the correct operator key set.
3. Verify the freeze admin account has sufficient HBAR balance.
4. Verify gossip endpoints and gRPC service endpoints are reachable from the network.
5. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

16 - SOLO-3017

NodeUpdateTransactionErrorSoloError

Description

Thrown when the node-update transaction fails to execute; when available the underlying failure is wrapped in cause. solo submits a node-update transaction to change a consensus node’s address-book entry (keys or endpoints), so this means the transaction was rejected or could not be submitted — for example the signing key was wrong, the updated values were invalid, or the network could not be reached.

Troubleshooting Steps

1. Verify the node admin key is correct and loaded from the k8s secret.
2. Confirm the node client is connected to the consensus network.
3. Check if the new account number is valid and funded.
4. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

17 - SOLO-3018

NodeDeleteTransactionErrorSoloError

Description

Thrown when the node-delete transaction fails to execute; when available the underlying failure is wrapped in cause. solo submits a node-delete transaction to remove a consensus node from the address book, so this means the transaction was rejected or could not be submitted — for example the admin key did not sign, the target node id was invalid, or the network could not be reached.

Troubleshooting Steps

1. Verify the node admin key is correct and loaded from the k8s secret.
2. Confirm the node exists in the current address book.
3. Verify gossip endpoints and gRPC service endpoints are reachable from the network.
4. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

18 - SOLO-3019

NodeCreateTransactionErrorSoloError

Description

Thrown when the node-create transaction fails to execute; when available the underlying failure is wrapped in cause. solo submits a node-create transaction to add a consensus node to the network’s address book, so this means the transaction was rejected or could not be submitted — for example the admin key did not sign, the node endpoints or parameters were invalid, or the network could not be reached.

Troubleshooting Steps

1. Verify gossip endpoints and gRPC service endpoints are reachable from the network.
2. Confirm the admin key is valid and the account has sufficient HBAR.
3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

19 - SOLO-3021

AccountBalanceQueryFailedSoloError

Description

Thrown when solo cannot read an account’s HBAR balance from the network via the Hedera SDK; the message names the account and, when present, wraps the underlying cause. solo queries balances to verify funding and confirm operations, so this is raised when the balance query does not return — typically because the target consensus node is unreachable or not yet ACTIVE, or the SDK client is misconfigured. It is retryable, since a transient network or node-readiness issue often clears on a later attempt.

Troubleshooting Steps

1. Verify gossip endpoints and gRPC service endpoints are reachable from the network.
2. Confirm the account ID is valid and exists on the network.
3. Review solo logs: tail -n 100 ~/.solo/logs/solo.log

20 - SOLO-3022

ExplorerDeployFailedSoloError

Description

Thrown when solo explorer node add cannot bring up the Hiero Explorer: the Helm release for the explorer chart failed to install, or its pods never reached a Ready state before solo stopped waiting. The original failure is wrapped in cause.message. Typical roots are an explorer image that cannot be pulled, misconfigured chart values (for example an unreachable mirror-node endpoint), a TLS/cert-manager prerequisite that is not ready, or insufficient cluster resources to schedule the pod.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Inspect explorer pods: kubectl get pods -A -l app.kubernetes.io/component=hiero-explorer
3. Inspect Helm release: helm status -n

21 - SOLO-3023

ExplorerUpgradeFailedSoloError

Description

Thrown when solo explorer node upgrade cannot upgrade the Hiero Explorer; the underlying failure is wrapped in cause. Upgrade re-applies the explorer Helm release at a new chart or version, so this means the upgrade did not succeed — for example a Helm failure, an image that cannot be pulled, or misconfigured values.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Inspect Helm release: helm status -n
3. View explorer pod logs: kubectl logs -n

22 - SOLO-3024

ExplorerDestroyFailedSoloError

Description

Thrown when solo explorer node destroy cannot tear down the Hiero Explorer; the underlying failure is wrapped in cause. Destroy uninstalls the explorer Helm release and removes its resources, so this means that teardown did not complete — for example a Helm release could not be removed or the cluster API was unreachable.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. List Helm releases: helm list -A
3. Force-uninstall if stuck: helm uninstall -n

23 - SOLO-3025

RelayDeployFailedSoloError

Description

Thrown when solo relay node add cannot deploy the JSON-RPC relay; the underlying failure is wrapped in cause. Deploy installs the relay Helm release, so this means that install did not succeed — for example a Helm failure, an image that cannot be pulled, misconfigured values (such as an unreachable network or mirror-node endpoint), or insufficient cluster resources.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Inspect relay pods: kubectl get pods -A -l app.kubernetes.io/instance=relay-
3. Inspect Helm release: helm status -n

24 - SOLO-3026

RelayUpgradeFailedSoloError

Description

Thrown when solo relay node upgrade cannot upgrade the JSON-RPC relay; the underlying failure is wrapped in cause. Upgrade re-applies the relay Helm release at a new chart or version, so this means the upgrade did not succeed — for example a Helm failure, an image that cannot be pulled, or misconfigured values.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Inspect Helm release: helm status -n
3. View relay pod logs: kubectl logs -n

25 - SOLO-3027

RelayDestroyFailedSoloError

Description

Thrown when solo relay node destroy cannot tear down the JSON-RPC relay; the underlying failure is wrapped in cause. Destroy uninstalls the relay Helm release and removes its resources, so this means teardown did not complete — for example a Helm release could not be removed or the cluster API was unreachable.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. List Helm releases: helm list -A
3. Force-uninstall if stuck: helm uninstall -n

26 - SOLO-3028

RelayNotRunningSoloError

Description

Thrown when a JSON-RPC relay that should be running is not; the message names the release and wraps the underlying failure in cause. solo checks that the relay pods are present and running before relying on it, so this means that check failed. It is retryable, since a relay that is still starting or briefly restarting often recovers on a later attempt.

Troubleshooting Steps

1. Check relay pod status: kubectl get pods -A | grep
2. View relay pod logs: kubectl logs -n -l app.kubernetes.io/instance=
3. Check solo logs: tail -n 100 ~/.solo/logs/solo.log

27 - SOLO-3029

RelayNotReadySoloError

Description

Thrown when a deployed JSON-RPC relay does not become ready in time; the message names the release and wraps the underlying failure in cause. solo waits for the relay pods to reach a Ready state after install, so this means that wait did not succeed in time. It is retryable, since a relay that is merely slow to start often becomes ready on a later attempt; a persistent failure points to a crash-looping or misconfigured relay.

Troubleshooting Steps

1. Check relay pod status: kubectl get pods -A | grep
2. Describe relay pods to check readiness probe failures: kubectl describe pods -A -l app.kubernetes.io/instance=
3. Check solo logs: tail -n 100 ~/.solo/logs/solo.log

28 - SOLO-3030

RelayOperatorKeyRetrievalFailedSoloError

Description

Thrown when solo cannot retrieve the operator key the JSON-RPC relay needs; the underlying failure is wrapped in cause. The relay signs transactions with an operator account key that solo reads (for example from a secret), so this means that retrieval failed. It is retryable, since a transient cluster or lookup problem often clears on a later attempt.

Troubleshooting Steps

1. Verify K8s API connectivity: kubectl get pods -n
2. If an operator key secret exists, verify it has a privateKey field: kubectl get secret -n -o yaml | grep privateKey
3. Check solo logs: tail -n 100 ~/.solo/logs/solo.log

29 - SOLO-3031

MirrorNodeDeployFailedSoloError

Description

Thrown when solo mirror node add cannot deploy the mirror node; the underlying failure is wrapped in cause. Deploy installs the mirror node Helm release (its importer, REST, and database components), so this means that install did not succeed — for example a Helm failure, an image that cannot be pulled, misconfigured values, or insufficient cluster resources.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Inspect mirror node pods: kubectl get pods -A -l app.kubernetes.io/instance=mirror-
3. Inspect Helm release: helm status -n

30 - SOLO-3032

MirrorNodeUpgradeFailedSoloError

Description

Thrown when solo mirror node upgrade cannot upgrade the mirror node; the underlying failure is wrapped in cause. Upgrade re-applies the mirror node Helm release at a new chart or version, so this means the upgrade did not succeed — for example a Helm failure, an image that cannot be pulled, or misconfigured values.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Inspect Helm release: helm status -n
3. View mirror node pod logs: kubectl logs -n

31 - SOLO-3033

MirrorNodeDestroyFailedSoloError

Description

Thrown when solo mirror node destroy cannot tear down the mirror node; the underlying failure is wrapped in cause. Destroy uninstalls the mirror node Helm release and removes its resources, so this means teardown did not complete — for example a Helm release could not be removed or the cluster API was unreachable.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. List Helm releases: helm list -A
3. Force-uninstall if stuck: helm uninstall -n

32 - SOLO-3034

MirrorNodeOperatorKeyRetrievalFailedSoloError

Description

Thrown when solo cannot retrieve the operator key the mirror node needs; the underlying failure is wrapped in cause. solo reads the operator account key (for example from a secret) so the mirror node can perform its operations, so this means that retrieval failed. It is retryable, since a transient cluster or lookup problem often clears on a later attempt.

Troubleshooting Steps

1. Verify K8s API connectivity: kubectl get pods -n
2. If an operator key secret exists, verify it has a privateKey field: kubectl get secret -n -o yaml | grep privateKey
3. Check solo logs: tail -n 100 ~/.solo/logs/solo.log

33 - SOLO-3035

OneShotDeployFailedSoloError

Description

Thrown when a one-shot deployment fails; the message describes the failing step and wraps the underlying failure in cause. One-shot mode brings up a complete network in a single command by running many deploy steps in sequence, so this means one of those steps did not succeed — the message identifies which, and common roots are Helm, image, or cluster-resource problems in the underlying step.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. If rollback was skipped, clean up partial resources: solo one-shot single destroy

34 - SOLO-3036

OneShotDestroyFailedSoloError

Description

Thrown when destroying a one-shot deployment fails; the underlying failure is wrapped in cause. One-shot destroy tears down everything a one-shot deploy created, so this means that teardown did not complete — for example a Helm release or cluster could not be removed, or the cluster API was unreachable.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. List remaining Helm releases: helm list -A
3. Delete stuck resources manually: kubectl delete -n

35 - SOLO-3037

OneShotDeploymentInfoRetrievalFailedSoloError

Description

Thrown when solo cannot retrieve information about a one-shot deployment; the underlying failure is wrapped in cause. solo reads deployment details (such as component status and endpoints) to report them, so this means that lookup failed — for example the cluster was unreachable or the expected resources were not found.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify kubeconfig context is valid: kubectl cluster-info

36 - SOLO-3038

FalconValuesPreparationFailedSoloError

Description

Thrown when solo cannot prepare the Falcon values file used during deployment; the underlying failure is wrapped in cause. solo assembles this Helm values file from configuration and runtime inputs before installing, so this means that preparation step failed — for example a required input was missing or invalid, or the file could not be written.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify the profile YAML is valid: solo deployment profile validate

37 - SOLO-3039

BlockNodeDeployFailedSoloError

Description

Thrown when solo block node add cannot deploy a block node; the underlying failure is wrapped in cause. Deploy installs the block node Helm release, so this means that install did not succeed — for example a Helm failure, an image that cannot be pulled, misconfigured values, or insufficient cluster resources.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Inspect block node pods: kubectl get pods -A -l block-node.hiero.com/type=block-node
3. Inspect Helm release: helm status -n
4. Check Helm history: helm history -n

38 - SOLO-3040

BlockNodeDestroyFailedSoloError

Description

Thrown when solo block node destroy cannot tear down a block node; the underlying failure is wrapped in cause. Destroy uninstalls the block node Helm release and removes its resources, so this means teardown did not complete — for example a Helm release could not be removed or the cluster API was unreachable.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Inspect block node pods: kubectl get pods -A -l block-node.hiero.com/type=block-node
3. Inspect Helm release: helm status -n
4. Check Helm history: helm history -n

39 - SOLO-3041

BlockNodeUpgradeFailedSoloError

Description

Thrown when solo block node upgrade cannot upgrade a block node; the underlying failure is wrapped in cause. Upgrade re-applies the block node Helm release at a new chart or version, so this means the upgrade did not succeed — for example a Helm failure, an image that cannot be pulled, or misconfigured values.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Inspect block node pods: kubectl get pods -A -l block-node.hiero.com/type=block-node
3. Inspect Helm release: helm status -n
4. Check Helm history: helm history -n

40 - SOLO-3042

BlockNodeAddExternalFailedSoloError

Description

Thrown when solo cannot register an external block node with the deployment; the underlying failure is wrapped in cause. Adding an external block node records a block node that runs outside this deployment so consensus nodes can use it, so this means that registration step failed — for example the provided endpoint was unreachable or the remote configuration could not be updated.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Inspect the remote config for the registered node: solo deployment config info
3. Inspect block node pods: kubectl get pods -A -l block-node.hiero.com/type=block-node
4. If the issue persists, report it with your solo log

41 - SOLO-3043

BlockNodeDeleteExternalFailedSoloError

Description

Thrown when solo cannot remove an external block node from the deployment; the underlying failure is wrapped in cause. Removing an external block node updates the configuration so consensus nodes no longer use it, so this means that removal step failed — for example the remote configuration could not be updated.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Inspect the remote config for the registered node: solo deployment config info
3. Inspect block node pods: kubectl get pods -A -l block-node.hiero.com/type=block-node
4. If the issue persists, report it with your solo log

42 - SOLO-3044

BlockNodeHealthCheckFailedSoloError

Description

Thrown when a block node health check does not pass; the message states the reason. solo health-checks a block node to confirm it is up and serving before relying on it, so this means the check reported the node unhealthy or could not reach it. It is retryable, since a block node that is still starting often passes on a later attempt.

Troubleshooting Steps

1. Check block node pod status: kubectl get pods -A -l block-node.hiero.com/type=block-node
2. Verify liveness endpoint manually: kubectl exec -n – curl http://localhost:/healthz/readyz
3. Check pod logs: kubectl logs -n -l block-node.hiero.com/type=block-node
4. Check solo logs: tail -n 100 ~/.solo/logs/solo.log

43 - SOLO-3045

RapidFireLoadStartFailedSoloError

Description

Thrown when solo cannot start a rapid-fire load run; the underlying failure is wrapped in cause. This step launches the load generator against the network, so this means startup failed — for example the load-test workload could not be created or scheduled. It is retryable, since transient cluster issues often clear on a later attempt.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Check NLG pod status: kubectl get pods -n -l app.kubernetes.io/instance=network-load-generator
3. Describe NLG pods for scheduling or image-pull errors: kubectl describe pods -n -l app.kubernetes.io/instance=network-load-generator
4. Check the NLG Helm release: helm status network-load-generator -n

44 - SOLO-3046

RapidFireLoadStopFailedSoloError

Description

Thrown when solo cannot stop a rapid-fire load run; the underlying failure is wrapped in cause. This step halts the running load generator, so this means the stop did not succeed — for example the workload could not be reached or removed.

Troubleshooting Steps

1. Check solo logs for the root cause: tail -n 100 ~/.solo/logs/solo.log
2. Check NLG pod status: kubectl get pods -n -l app.kubernetes.io/instance=network-load-generator
3. Check for running NLG Java processes: kubectl exec -n – ps aux | grep java
4. To force-stop, uninstall the NLG chart: helm uninstall network-load-generator -n

45 - SOLO-3047

RapidFireKillFailedSoloError

Description

Thrown when solo cannot stop a running rapid-fire load test; the message names the test class and wraps the underlying failure in cause. This step terminates the load generator, so this means the stop did not succeed — for example the load-test pod or process could not be reached or signaled.

Troubleshooting Steps

1. Check if the test process is still running: kubectl exec -n – ps aux | grep
2. Manually kill the process: kubectl exec -n – pkill -f
3. To stop the load test entirely, uninstall the NLG chart: helm uninstall network-load-generator -n

46 - SOLO-3048

AccountCreationFailedSoloError

Description

Thrown when creating a Hedera account through the SDK fails; the underlying failure is wrapped in cause. solo creates accounts (for example operator or treasury accounts) during network setup, so this means the create transaction did not succeed — commonly because the network rejected it (insufficient payer balance, key problems) or the consensus node could not be reached.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify consensus nodes are running: kubectl get pods -n
3. Check node logs for errors: kubectl logs -n
4. Create a new account: solo ledger account create

47 - SOLO-3049

AccountKeyUpdateFailedSoloError

Description

Thrown when updating the keys on a Hedera account fails; the message names the account. solo rotates account keys (for example replacing genesis keys) with an update transaction, so this means that transaction did not succeed — commonly because the existing key did not sign correctly, the new key is invalid, or the network rejected or could not be reached.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify consensus nodes are running: kubectl get pods -n
3. Verify the account ID is correct and the account exists on the network

48 - SOLO-3050

AccountKeysBatchUpdateFailedSoloError

Description

Thrown when a batch key-update over several accounts does not fully succeed; the message reports how many accounts were not updated. solo updates account keys in bulk during setup and raises this when one or more of those updates is rejected — typically due to signing or key problems on the affected accounts, or transient network failures while submitting the batch.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify consensus nodes are running: kubectl get pods -n
3. Verify operator account has sufficient permissions
4. Update individual accounts: solo ledger account update

49 - SOLO-3051

AccountTransferFailedSoloError

Description

Thrown when an HBAR transfer transaction fails; the underlying failure is wrapped in cause. solo transfers HBAR to fund accounts during setup and account operations, so this means the transfer was rejected or could not be submitted — commonly an insufficient sender balance, a signing problem, or an unreachable consensus node.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify consensus nodes are running: kubectl get pods -n
3. Verify the sender account has sufficient HBAR balance

50 - SOLO-3052

AccountInfoFailedSoloError

Description

Thrown when solo cannot retrieve an account’s information from the network via the SDK; the underlying failure is wrapped in cause. It means the account-info query did not return — for example the account does not exist, the consensus node is unreachable or not yet ACTIVE, or the SDK client is misconfigured.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify consensus nodes are running: kubectl get pods -n
3. Verify the account ID exists on the network

51 - SOLO-3053

AccountUpdateFailedSoloError

Description

Thrown when updating a Hedera account’s properties fails; the message names the account. solo submits an account-update transaction to change account settings, so this means that transaction did not succeed — for example the account’s key did not sign, the requested change was invalid, or the network rejected or could not be reached.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify consensus nodes are running: kubectl get pods -n
3. Verify the account exists on the network: solo ledger account update

52 - SOLO-3054

AccountSecretCreationFailedSoloError

Description

Thrown when solo cannot store an account’s key material as a Kubernetes secret; the message names the account. After creating or updating an account, solo persists its keys in a cluster secret so other components can use them, so this is raised when that secret cannot be created — for example the namespace is missing, a conflicting secret exists, or the Kubernetes API rejected the request.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify Kubernetes connectivity: kubectl get pods -n
3. Check existing secrets: kubectl get secrets -n
4. Verify RBAC permissions allow secret creation

53 - SOLO-3055

EvmAddressRetrievalFailedSoloError

Description

Thrown when solo cannot determine the EVM address associated with a Hedera account; the message names the account. solo derives or looks up the account EVM (alias) address for EVM-compatible workflows, so this is raised when that lookup fails — for example the account has no EVM address, or its account info could not be retrieved from the network.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify consensus nodes are running: kubectl get pods -n
3. Verify the account ID is valid and the account exists on the network

54 - SOLO-3056

NodeAccessConfigFailedSoloError

Description

Thrown when solo cannot configure access to a consensus node; the underlying failure is wrapped in cause. This step establishes the connection (such as a port-forward) and credentials needed to reach a node, so this means that configuration failed — for example the node pod or service was not reachable, or a required port-forward could not be created.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify consensus node pods are running: kubectl get pods -n
3. Check node logs: kubectl logs -n
4. Restart the consensus node: solo consensus node restart

55 - SOLO-3057

NodeClientLoadFailedSoloError

Description

Thrown when solo cannot load the Hedera SDK client used to talk to the network; the underlying failure is wrapped in cause. The client is built from network and node connection details plus operator credentials, so this means that load step failed — for example the node services or endpoints could not be resolved, or the operator key was missing or invalid.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify consensus node pods are running: kubectl get pods -n
3. Inspect node pod logs: kubectl logs -n
4. Verify network port-forwards are active: solo deployment refresh port-forwards

56 - SOLO-3058

NodeClientRefreshFailedSoloError

Description

Thrown when solo cannot refresh the Hedera SDK client’s view of the network; the underlying failure is wrapped in cause. solo refreshes the client when the network’s nodes or endpoints change, so this means re-resolving the connection details failed — for example node services could not be retrieved or the new endpoints were unreachable.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify consensus node pods are running: kubectl get pods -n
3. Inspect node pod logs: kubectl logs -n
4. Verify network port-forwards are active: solo deployment refresh port-forwards

57 - SOLO-3059

NodeClientSetupFailedSoloError

Description

Thrown when solo cannot set up the Hedera SDK client for the network; the underlying failure is wrapped in cause. Setup wires the client to the network node endpoints and operator account before any SDK calls, so this means that configuration step failed — for example endpoints could not be resolved or operator credentials were missing or invalid.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify consensus node pods are running: kubectl get pods -n
3. Check port-forward status: solo deployment refresh port-forwards
4. Inspect node logs: kubectl logs -n

58 - SOLO-3060

SdkPingFailedSoloError

Description

Thrown when solo SDK ping to a network node does not succeed within the allowed retries; the message names the node alias and the number of retries tried. solo pings nodes to confirm they are reachable and responsive before relying on them, and raises this once retries are exhausted. It is retryable because a node that is merely slow to start often responds on a later attempt; a persistent failure points to a node that is down or unreachable.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify the node pod is running: kubectl get pods -n -l solo.hedera.com/node-name=
3. Inspect node logs: kubectl logs -n
4. Check port-forward status: solo deployment refresh port-forwards
5. Restart the node: solo consensus node restart

59 - SOLO-3061

NodeServicesRetrievalFailedSoloError

Description

Thrown when solo cannot retrieve the Kubernetes services for the network’s consensus nodes; the underlying failure is wrapped in cause. solo reads these services to discover node endpoints, so this means the lookup failed — for example the namespace is wrong, the services do not exist yet, or the Kubernetes API was unreachable.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. List Kubernetes services in the namespace: kubectl get svc -n
3. Verify consensus nodes are deployed: kubectl get pods -n

60 - SOLO-3062

GossipKeySecretCreationFailedSoloError

Description

Thrown when solo cannot store a consensus node’s gossip keys as a Kubernetes secret; the message names the node alias. Gossip keys secure node-to-node communication and are mounted from a cluster secret, so this means that secret could not be created — for example the namespace is missing, a conflicting secret exists, or the Kubernetes API rejected the request.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Check existing secrets: kubectl get secrets -n
3. Verify RBAC permissions allow secret creation in the namespace
4. Re-run node setup: solo consensus node setup

61 - SOLO-3063

TlsKeySecretCreationFailedSoloError

Description

Thrown when solo cannot store a generated TLS key as a Kubernetes secret; when available the underlying failure is wrapped in cause. solo persists TLS keys in cluster secrets so components can mount them, so this means the secret could not be created — for example the namespace is missing, a conflicting secret exists, or the Kubernetes API rejected the request.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Check existing secrets: kubectl get secrets -n
3. Verify RBAC permissions allow secret creation in the namespace
4. Re-run node setup: solo consensus node setup

62 - SOLO-3064

TlsKeyGenerationFailedSoloError

Description

Thrown when solo cannot generate a TLS key; the message includes the underlying error text. solo generates TLS keys to secure node communication, so this means generation failed — for example the key-generation tooling errored or a working file could not be written.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify required key generation tools are available
3. Re-run node setup: solo consensus node setup

63 - SOLO-3065

SigningKeyGenerationFailedSoloError

Description

Thrown when solo cannot generate a node signing key; the underlying failure is wrapped in cause. Signing keys establish a consensus node identity, so this means generation failed — for example the key-generation tooling errored or a working file could not be written.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify key generation tools are available
3. Re-run key generation: solo keys consensus

64 - SOLO-3066

GrpcTlsKeyGenerationFailedSoloError

Description

Thrown when solo cannot generate the gRPC TLS key for a consensus node; the underlying failure is wrapped in cause. solo generates this key to secure node gRPC traffic, so this means key generation failed — for example the key-generation tooling errored or a working file could not be written.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify key generation tools are available
3. Re-run node setup: solo consensus node setup

65 - SOLO-3067

GrpcTlsCertMismatchSoloError

Description

Thrown when the gRPC TLS certificate and key supplied by the user do not correspond; the message lists the certificate and key paths. solo pairs each provided certificate with its key for node gRPC TLS, so this means the structures do not match — typically a certificate and key from different pairs, or paths that were swapped or point to the wrong files.

Troubleshooting Steps

1. Ensure the number of certificate paths matches the number of key paths
2. Each certificate must have a corresponding private key in the same position
3. Verify the certificate and key files exist at the specified paths

66 - SOLO-3068

GrpcWebTlsCertMismatchSoloError

Description

Thrown when the gRPC Web TLS certificate and key supplied by the user do not correspond; the message lists the certificate and key paths. solo pairs each provided certificate with its key for the node’s gRPC Web TLS, so this means the structures do not match — typically a certificate and key from different pairs, or paths that were swapped or point to the wrong files.

Troubleshooting Steps

1. Ensure the number of certificate paths matches the number of key paths
2. Each certificate must have a corresponding private key in the same position
3. Verify the certificate and key files exist at the specified paths

67 - SOLO-3069

CertificateSecretCreationFailedSoloError

Description

Thrown when solo cannot create the TLS certificate secret for a consensus node; the message names the node alias. solo stores node certificates as Kubernetes secrets so they can be mounted, so this means the secret could not be created — for example the namespace is missing, a conflicting secret exists, or the Kubernetes API rejected the request.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Check existing secrets: kubectl get secrets -n
3. Verify RBAC permissions allow secret creation
4. Re-run node setup: solo consensus node setup

68 - SOLO-3070

CertificateParsingFailedSoloError

Description

Thrown when solo cannot parse a certificate input the user provided; the message names the input, its type, and the line and index of the offending entry. solo parses each supplied certificate to validate and use it, so this means the content is not valid for the expected format — for example a malformed or truncated certificate, or the wrong kind of file supplied.

Troubleshooting Steps

1. Verify the certificate input format is correct for the expected type
2. Check the value at line , position of the input
3. Ensure certificate values are properly formatted (PEM or DER encoded)

69 - SOLO-3071

CertificateFileNotFoundSoloError

Description

Thrown when a certificate file the user referenced does not exist at the given path; the message names the path and input type, with the line and index of the offending entry. solo reads certificate files from the paths provided on the command line or in configuration, so this means the file is missing or the path is wrong — for example a typo, a relative path resolved from an unexpected directory, or a file that was moved.

Troubleshooting Steps

1. Verify the file exists at the path:
2. Ensure the path is absolute or relative to the working directory
3. Check file permissions allow reading the certificate file

70 - SOLO-3072

ExplorerTlsSecretCreationFailedSoloError

Description

Thrown when solo cannot create the TLS certificate secret used by the Hiero Explorer; when available the underlying failure is wrapped in cause. The explorer is served over TLS using a certificate stored as a Kubernetes secret, so this means that secret could not be created — for example the namespace is missing, a conflicting secret exists, or the Kubernetes API rejected the request.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Check existing secrets: kubectl get secrets -n
3. Verify RBAC permissions allow secret creation
4. Re-deploy the explorer: solo explorer node add

71 - SOLO-3073

PlatformFileNotFoundSoloError

Description

Thrown when a platform file solo needs does not exist; the message names the path. solo reads platform artifacts from expected locations during setup, so this means the file is missing — for example the platform build was incomplete, an earlier download or extract step did not produce it, or the path is wrong.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify the file exists at:
3. Ensure the node build artifacts are present and the build path is correct

72 - SOLO-3074

PlatformFileCopyFailedSoloError

Description

Thrown when solo cannot copy platform files into a consensus node pod; the message names the source files, the pod, and the destination directory, and wraps the underlying failure in cause. solo copies platform artifacts into the node container during setup, so this means the copy failed — for example the pod was not reachable, the destination path was not writable, or the connection dropped mid-copy.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify the pod is running: kubectl get pod -n
3. Check available disk space in the pod
4. Inspect pod logs: kubectl logs -n

73 - SOLO-3075

PlatformKeyFileMissingSoloError

Description

Thrown when a required key file is missing; the message names the file. solo expects certain key files to be present when provisioning a node, so this means one of them was not found — for example key generation did not produce it, or it was not copied into the expected location.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify the key file exists at:
3. Re-generate keys if needed: solo keys consensus
4. Re-run node setup: solo consensus node setup

74 - SOLO-3076

GenesisAdminKeySecretFailedSoloError

Description

Thrown when solo cannot store a genesis account’s admin key as a Kubernetes secret; the message names the account. During genesis setup solo persists admin keys in cluster secrets for later use, so this is raised when that secret cannot be created — for example the namespace is missing, a conflicting secret exists, or the Kubernetes API rejected the request.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Check existing secrets: kubectl get secrets -n
3. Verify RBAC permissions allow secret creation
4. Redeploy the network: solo consensus network deploy

75 - SOLO-3077

GenesisDataGenerationFailedSoloError

Description

Thrown when solo fails to generate the genesis data used to bootstrap a new network; the underlying failure is wrapped in cause. Genesis generation produces the initial accounts, keys, and configuration the network starts from, so this means that generation step did not complete — for example required inputs were missing or invalid, or a file could not be written.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify all consensus node configurations are correct
3. Check deployment configuration: solo deployment config info
4. Redeploy the network: solo consensus network deploy

76 - SOLO-3078

PostgresInitScriptCopyFailedSoloError

Description

Thrown when solo cannot copy the mirror node Postgres initialization script into its container; the message names the namespace and wraps the underlying failure in cause. solo copies this script into the database container before running it, so this means the copy failed — for example the target container or pod was not reachable, or the destination was not writable.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify the Postgres pod is running: kubectl get pods -n -l app.kubernetes.io/name=postgresql
3. Inspect Postgres pod logs: kubectl logs -n
4. Re-deploy the mirror node: solo mirror node add

77 - SOLO-3079

PostgresInitScriptFailedSoloError

Description

Thrown when the mirror node Postgres initialization script fails to run; the message includes the number of attempts made and wraps the underlying failure. solo runs this script to initialize the mirror node database, so this means execution did not succeed across the attempts tried — for example the database was not ready or the script returned an error. It is retryable, since a database that is still starting often accepts the script on a later attempt.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Inspect Postgres pod logs: kubectl logs -n
3. Check Postgres pod status: kubectl describe pod -n
4. Re-deploy the mirror node: solo mirror node add

78 - SOLO-3080

MirrorPasswordSecretMissingSoloError

Description

Thrown when the mirror node database owner credential is absent from the expected secret — specifically MIRROR_IMPORTER_DB_OWNER is not present in the mirror-passwords secret. solo reads this secret to obtain the importer’s database owner, so this means the secret exists without the required key, or was not populated as expected during deployment.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Inspect the mirror-passwords secret: kubectl get secret mirror-passwords -n -o jsonpath="{.data}"
3. Re-deploy the mirror node to recreate secrets: solo mirror node add

79 - SOLO-3081

FileContentVerificationFailedSoloError

Description

Thrown when solo’s verification of a file’s content fails; the message describes what was being verified. solo verifies file content at certain steps to ensure it matches the expected value, so this means that check did not pass — the content was missing, incomplete, or different from what was required.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify consensus nodes are running and healthy: kubectl get pods -n
3. Inspect node logs for errors: kubectl logs -n

80 - SOLO-3082

HederaFileCreationFailedSoloError

Description

Thrown when a Hedera File Service create transaction returns a non-success status; the message includes the network status. solo uses the File Service to store artifacts on the network (such as upgrade files), so this means the file create was rejected — the specific status code identifies why, for example a payer or signature problem or an invalid file.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify consensus nodes are running: kubectl get pods -n
3. Consult the Hedera documentation for the meaning of the status code

81 - SOLO-3083

HederaFileUpdateFailedSoloError

Description

Thrown when a Hedera File Service update transaction returns a non-success status; the message includes the network status. solo updates network-stored files (such as upgrade files) via the File Service, so this means the update was rejected — the specific status code identifies why.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify consensus nodes are running: kubectl get pods -n
3. Consult the Hedera documentation for the meaning of the status code

82 - SOLO-3084

HederaFileAppendFailedSoloError

Description

Thrown when a Hedera File Service append transaction returns a non-success status; the message includes the chunk index and the network status. Large files are uploaded in chunks, so this means appending a particular chunk was rejected — the specific status code identifies why, for example a size limit or a payer or signature problem.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify consensus nodes are running: kubectl get pods -n
3. Consult the Hedera documentation for the meaning of the status code

83 - SOLO-3085

NodeStatusEmptyResponseSoloError

Description

Thrown when a consensus node’s status check returns an empty response. solo queries each node’s status endpoint to determine its state, so an empty reply means the node returned nothing usable — typically because the node is not yet serving its status endpoint, or the request reached a target that is not ready.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify the consensus node pod is running: kubectl get pods -n
3. Inspect node logs: kubectl logs -n

84 - SOLO-3086

NodeStatusMissingLineSoloError

Description

Thrown when a consensus node’s status check response is missing the expected status line. solo parses the status output to read the node’s current state, so this means the response came back but did not contain the line solo needs — usually because the node is still starting and has not produced full status output, or the output format was unexpected.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify the consensus node pod is running: kubectl get pods -n
3. Inspect node logs: kubectl logs -n

85 - SOLO-3087

PredefinedAccountsCreationFailedSoloError

Description

Thrown when solo fails to create the set of predefined accounts it seeds into a new network; the underlying failure is wrapped in cause. These accounts are created during setup to provide ready-to-use funded accounts, so this means one of those creations did not succeed — commonly a network rejection, a signing or key problem, or an unreachable consensus node.

Troubleshooting Steps

1. Check solo logs: tail -n 100 ~/.solo/logs/solo.log
2. Verify consensus nodes are running: kubectl get pods -n
3. Check node logs for errors: kubectl logs -n

86 - SOLO-3088

FileContentMismatchSoloError

Description

Thrown when content read back from the network does not match what solo uploaded. After uploading a file (for example via the Hedera File Service), solo re-reads it and compares, so this means the round-trip verification failed — the stored content differs from what was sent, indicating the upload was incomplete or corrupted.

Troubleshooting Steps

1. Retry the file upload — transient network issues can cause partial or corrupt writes
2. Check solo logs for chunk append errors: tail -n 100 ~/.solo/logs/solo.log
3. Verify consensus nodes are healthy: kubectl get pods -n
4. Check node logs for transaction errors: kubectl logs -n
5. Confirm no concurrent process modified the same Hedera file during the upload

87 - SOLO-3089

NodeServiceNotFoundSoloError

Description

Thrown when solo cannot resolve the Kubernetes service for a specific consensus node; the message names the node alias. solo expects each node to expose a service it can reach, so this is raised when no matching service is found — typically because the node alias does not correspond to a deployed node, or the selected deployment or namespace does not contain it.

Troubleshooting Steps

1. Verify that node ‘’ exists in the deployment: solo deployment info
2. List all node services in the namespace: kubectl get svc -n
3. Check that the consensus node pod is running: kubectl get pods -n -l app=
4. Check solo logs for more context: tail -n 100 ~/.solo/logs/solo.log