Troubleshooting

Start with the visible symptom. Preserve the Gateway output, package-manager output, generated package version, runtime versions, and the first complete exception before changing configuration.

Choose the symptom

Capture this data first

  1. The exact Receiver module path and runtime selected by Gateway.
  2. Gateway startup output from process start through module analysis and publication.
  3. The package-manager command copied from that same running Gateway/Vision.
  4. Receiver, Gateway, generated package, Hypertube dependency, and caller runtime versions.
  5. Resolved Graft host and execution mode: in-memory, WebSocket, HTTP/2, TCP, or plugin.
  6. Whether the failure occurs before publication, during installation, at the first call, or after a restart.

Do not post project keys, JWTs, authorization headers, private registry credentials, or package-manager credential files. Redact values while preserving header names, status codes, and error categories.

Diagnostic boundaries

  • Package generation and package installation happen before normal runtime calls.
  • Vision describes the Gateway process that hosts it; another Gateway can show a different model.
  • Discovery does not prove that every target ecosystem accepts the discovered types.
  • A remote failure has network and authentication causes that do not exist in in-memory mode.
  • Generated runtime context is cached after first initialization; late configuration changes may not affect the current process.

Next steps

Open the symptom page above. If no page matches, reduce the issue to the earliest failing stage: discovery, publication, installation, import/compile, connection, authentication, invocation, or result mapping.