> For the complete documentation index, see [llms.txt](https://docs.talus.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.talus.network/faq/08-troubleshooting.md). # Troubleshooting {% hint style="info" %} **Audience:** Nexus adopters and integrators. **Goal:** Answer common failure symptoms and safe recovery limits so you can collect the right evidence before retrying or replacing work. {% endhint %} This page holds the cross-cutting failure gotchas that are nobody's single domain — the surprises that bite in practice. It is deliberately short: most questions belong to a specific concern (a failed step is authoring’s post-failure semantics; a stuck run belongs to [DAG and Execution](/concepts/05-workflow-dag-execution.md) and [On-Chain Result Resolution](/concepts/11-onchain-result-resolution.md); a rejected result is verification). Only questions that cut across those live here. #### CLI discovery and historical evidence **Why did an old successful Execution become impossible to inspect?** Testnet prunes transaction history, sometimes after only a few days. `history is incomplete: missing transaction …` means the CLI cannot reconstruct the required history; it does not prove the run failed or remained unpaid. A Task or Occurrence can still exist after its supporting transaction history becomes unavailable. Save Execution output, effects, receipts, IDs, CLI version, network, and collection time immediately after each walk. Use archived evidence with its original timestamp; a newly authorized walk supplies fresh evidence for new IDs, not recovery of the old run. See [Capture Testnet evidence promptly](/guides/agent-usage/execute-and-settle-agent.md#capture-testnet-evidence-promptly). #### Confidentiality and transport **Is the data flowing between the leader and my tool encrypted end-to-end?** The transport is encrypted, but the payload is not confidential *from the leader*. Leader-to-tool calls run over HTTPS, so the connection is protected against outside observers, and signed HTTP adds authenticity and integrity on top. What is **not** provided is end-to-end confidentiality that hides the request or response contents *from the leader itself*: the leader sees the plaintext of what it sends to and receives from a tool. There is no protocol-level encryption layer that would keep a tool's inputs or outputs secret from the leader. This is a deliberate boundary, not an oversight. An earlier design placed decryption authority in the leader, which is incompatible with the direction of a permissionless leader network — the party that runs the leader should not be the party that holds every secret. Rather than ship an encryption scheme that puts authority in the wrong place, the protocol leaves confidentiality to the tool. The practical consequences: * **Secrets a tool needs (like API keys) belong inside the tool.** Build "fat" tools that hold and use their own credentials internally and charge per invocation, rather than passing a secret through the leader to the tool. * **Sensitive workflow data is visible.** Prompts, completions, and other payloads that pass through the leader — and anything written to remote storage — should be treated as visible, not private. Design workflows on the assumption that their data is not hidden from the service or other authorized readers. If your use case truly requires that the leader not see certain data, keep that data and its handling inside a tool you control, and expose only the non-sensitive result to the workflow. **Why is my data readable in remote storage?** Because the protocol does not encrypt it. A caller explicitly selects remote storage per value (for example with `--remote`); larger payloads are not silently secret. Remote storage (Walrus by default) stores data as-is, and anyone with access to the stored blob can read it. If a remote read is unavailable, retry only within the configured Leader timeout/budget; retry exhaustion produces no result and follows the normal timeout/recovery path. A digest mismatch is an integrity failure, not an availability retry. Retention, restore, and cleanup are provider/operator responsibilities, so a reference can outlive a retained blob. If a payload must be confidential, encrypt it inside the tool that produces it before it leaves the tool, and store only what you are willing to expose. Public readers can inspect the stored reference and transaction evidence; private service configuration is outside this FAQ. *** **Where do I go next?** * [DAG and Execution](/concepts/05-workflow-dag-execution.md) — public dispatch and execution state. * [On-Chain Result Resolution](/concepts/11-onchain-result-resolution.md) — pending results, shortfalls, retries, and timeout resolution. * [Authoring](/faq/03-authoring.md) — a step's post-failure behavior and error variants. * [Verification](/faq/06-verification.md) — why a result was rejected, and the trust modes. * [Glossary](/glossary/glossary.md) — leader, network, and data-storage terms. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.talus.network/faq/08-troubleshooting.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.