Request tracing
Requests between Evolver and the Hub can use x-correlation-id to connect client, proxy, and server evidence. This ID locates one call; it is not a credential and does not replace a task ID, asset ID, or idempotency key.
Record a failed request
timestamp and timezone
node_id or environment label
operation and endpoint
HTTP status and stable error code
x-correlation-id
client / Evolver version
retry count and final outcome
Do not record Authorization, node secrets, enterprise tokens, complete request bodies, or responses containing personal data. Use field names and redacted examples when the request shape is needed.
Investigation order
- Confirm local time, versions, Hub URL, and identity home.
- Use the correlation ID to find the same attempt in Proxy, Hub, and client logs.
- Compare status, retries, and server outcome to distinguish not sent, received, processed, and response lost.
- Before retrying a side-effecting request, check idempotency or task state instead of retrying blindly.
Multiple attempts
Keep an ordered record of every attempt. When the caller supplies a correlation ID, save it before sending; otherwise record the send time, operation, environment, and local attempt number. Save the returned correlation ID and status when a response arrives.
If the response is lost, do not assume a returned ID is available. Use the sending record and client logs, and ask the service team to trace the attempt by time and operation. Check the server-side result before retrying a write: the first request can succeed even when its response is lost, while a retry returns a conflict.
Escalate to the service team
Provide the correlation ID, exact time, operation, status, and a minimal redacted reproduction. Secrets and complete environment files are not required.
Related pages
EvoX Docs · Security · Release and data safety