Troubleshoot with the Assistant v2
Use the assistant to interpret current diagnostics and logs, propose a focused repair, and retest the affected path. Keep the evidence and desired scope explicit.
Collect the latest evidence
- Reproduce the problem in the intended Environment and Cluster with the smallest safe input.
- Open
Problemsfor authoring or compilation failures. - Open
Logsand identify the latest failed Step, message, inputs, and outputs for runtime failures. - Confirm whether the failing design is the unsaved Canvas, saved Test revision, or a published revision in another Environment.
Ask for a narrow diagnosis
Tell the assistant:
- The expected result.
- The exact diagnostic or failed Step.
- The input shape used.
- The Environment and Cluster.
- What the assistant may change.
- Which side effects must not be repeated.
Ask it to inspect the relevant contract and change only the smallest affected region. Avoid prompts such as “fix everything,” which can obscure the original cause and broaden mutation risk.
Review and retest
- Review the proposed YAML and explanation.
- Reject any invented field, Node version, Connection, or identifier.
- Accept the proposal only when its scope matches the diagnosis.
- Run the same controlled test again.
- Compare the latest log with the original failure.
- Repeat for the next gating failure rather than changing unrelated Steps at once.
Access boundaries
The assistant can use the current Workflow, discovered Node/Method contracts, compatible Connection identities, diagnostics, and permitted log data. It cannot reveal protected Connection values. Redaction and log-storage limits still apply, so missing values may require a safer authored Sample or a controlled rerun.
The assistant does not replace external-system verification, production authorization, release review, or the user's decision to repeat a mutation. Save only the tested proposal.
See also
See Use the Workflow Assistant, Assistant Pane, and Mapping and Expression Errors.