Skip to content

fix(zboss): make permitJoin loud when the driver is not initialized - #1829

Open
tostmann wants to merge 1 commit into
Koenkk:masterfrom
tostmann:fix/zboss-permitjoin-loud
Open

fix(zboss): make permitJoin loud when the driver is not initialized#1829
tostmann wants to merge 1 commit into
Koenkk:masterfrom
tostmann:fix/zboss-permitjoin-loud

Conversation

@tostmann

Copy link
Copy Markdown
Contributor

permitJoin() wraps its entire body in if (this.driver.isInitialized()) with no else branch. Called while the driver is not initialized, the request simply evaporates — no log, no error — and the application above reports the permit as successful although nothing was sent on the wire. During a recent debugging session this exact shape cost hours: "the network never opens although permit_join returns ok" with nothing in any log to point at the guard.

This adds the missing else: an explicit logger.error stating the request was ignored and the network state unchanged.

Deliberately log-only rather than a throw, since the guard also covers internal timer-driven calls around shutdown, where a rejection would surface as an unhandled one — but happy to switch to a throw if you prefer that contract.

Covered by a unit test (spied logger, fake uninitialized driver: resolves without throwing, error line emitted) that fails on the previous code. Full vitest suite and pnpm run check green.

permitJoin() wraps its entire body in `if (this.driver.isInitialized())`
with no else branch: called while the driver is not initialized, the request
simply evaporates — no log, no error — and the application above reports the
permit as successful although nothing was sent. That silent shape turns any
join problem in this state into a dead-end diagnosis.

Add the missing else: log an explicit error stating the request was ignored
and the network state unchanged. Deliberately log-only rather than a throw —
the guard also covers internal timer-driven calls around shutdown, where a
rejection would surface as an unhandled one. Happy to switch to a throw if
that contract is preferred.
@Nerivec

Nerivec commented Jul 30, 2026

Copy link
Copy Markdown
Collaborator

I would assume it shouldn't be possible for permitJoin to ever be called if the driver is not initialized. Once adapter.start() returns, ZH assumes it is in working condition, else disconnected event should have been triggered.

@tostmann

Copy link
Copy Markdown
Contributor Author

Agreed — in the upstream flows that state shouldn't be reachable: once start() has returned, either the driver is up or disconnected has fired.

The wrinkle is that the guard already exists in permitJoin() today, and its only observable behavior is the silent swallow: if the assumption ever breaks (adapter teardown racing a late request, or a future driver change), the request evaporates while the application above reports success.

So there are two consistent ways to express "this can't happen":

  1. drop the guard entirely — permitJoin() then behaves like the other adapters, and an uninitialized driver surfaces naturally as a failed command; or
  2. keep it defensive but loud (this PR).

Happy to rework the PR to (1) if that's the preferred contract — it's the cleaner expression of the assumption.

@Nerivec

Nerivec commented Jul 30, 2026

Copy link
Copy Markdown
Collaborator

I'd say 1, but let's wait confirmation from @Koenkk @kirovilya

@Koenkk

Koenkk commented Jul 30, 2026

Copy link
Copy Markdown
Owner

@kirovilya could you check?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants