feat(node-red): recover streaming nodes from auth failures without redeploy - #96
Conversation
…deploy TeslemetryStream stops reconnecting for good after two consecutive auth_failure events, leaving teslemetry-event/-signal/-energy-event stuck until the flow was redeployed. Add attachStreamStatus() in shared.ts to give these nodes a distinct auth-error status (vs. an ordinary stream_error reconnect) and resume the stream automatically once the retry delay elapses.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c721de605a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const onDisconnect = () => { | ||
| node.status({ fill: "red", shape: "ring", text: "disconnected" }); |
There was a problem hiding this comment.
Keep the authentication failure status visible
After the second consecutive 401/403, TeslemetryStream emits auth_failure and then unconditionally emits disconnect as its loop exits. Consequently, onAuthFailure briefly sets the actionable “auth failed - check token” status, but this handler immediately replaces it with generic “disconnected” for the entire 60-second retry interval, defeating the new distinction between authentication failures and ordinary disconnections. Preserve the authentication state when handling that terminal disconnect.
AGENTS.md reference: AGENTS.md:L96-L96
Useful? React with 👍 / 👎.
Intent
TeslemetryStream's reconnect loop gives up permanently after two consecutiveauth_failureevents, but the Node-RED streaming nodes (teslemetry-event,teslemetry-signal,teslemetry-energy-event) only ever showed a generic red "disconnected" status for that - indistinguishable from an ordinary network blip, and with no way to recover short of redeploying the flow.attachStreamStatus()insrc/shared.ts, wiringconnect/disconnect/stream_error/auth_failureonto a node's status indicator and replacing each node's near-identical listener block.stream_errornow shows a yellow "reconnecting (attempt N)" or "auth error, retrying" status while the SDK's own backoff is still retrying.auth_failureshows a red "auth failed - check token" status and schedules asse.connect()retry after a delay, since the SDK won't resume the stream on its own once it stops - a bad token clearing (or a transient IdP hiccup) now recovers automatically instead of requiring a redeploy.