Skip to main content

Troubleshooting

Symptoms are grouped by the activity you were doing when they appeared. Each entry states the symptom first; scan the headings for yours. Release-specific symptom tables live in the upgrade guides themselves.

Installation​

API Crash-Loops with ERR_INVALID_ARG_VALUE Hex Errors​

A license value created with echo instead of echo -n carries a trailing newline and crash-loops the API service. Create license secrets with echo -n or printf:

Create the license secret without a trailing newline
printf '%s' '<license-value>' | kubectl -n <namespace> create secret generic <license-secret-name> --from-file=license=/dev/stdin

AccessDenied on Artifact Writes​

Writable-artifact configuration points at the read-only models bucket. The two object stores must stay separate as required by the object storage dependency; repoint the writable-artifact configuration at the platform-artifact store.

no matches for kind "Certificate" During Install​

The platform chart is being installed on a cluster where the cert-manager CRDs do not yet exist. Install cert-manager first; it is layer 1 of the install order and is deliberately never bundled as a subchart.

Configuration Changes​

Config Fix Applied but the Pod Keeps Crashing with the Old Error​

When a component's environment comes from a ConfigMap via envFrom, the environment is resolved at pod creation; container restarts reuse stale values. Delete the pod so its controller recreates it:

Recreate the pod to pick up new envFrom values
kubectl -n <namespace> delete pod <pod-name>

ConfigMap Still Shows a Removed Key After a Successful Upgrade​

Drift from an earlier failed upgrade attempt: Helm's three-way merge only diffs against the last deployed manifest and does not delete keys it never deployed. Remove the stray key manually, then recreate the affected pod (see the previous symptom).

Pods Still Using an Old Endpoint After a Secret Change​

Environment variables are read at container start. Restart the consumers:

Roll the consumers of the changed secret
kubectl -n <namespace> rollout restart deployment <deployment-name>

Release-Specific Symptoms​

Each upgrade guide carries the symptom table validated during that migration:

Escalation​

If a symptom is not listed here, collect the failing component's logs and recent Helm history before contacting your DynamoAI deployment engineer:

Collect context for escalation
kubectl -n <namespace> get pods
kubectl -n <namespace> logs <failing-pod> --previous
helm -n <namespace> history <release-name>
Last updated on