app

NB - Native Browser Bridge

Public Made by Adom

by adom

Your real browser, driven by AI.

nbnbeabbridgeadom-bridgenb-bridgenative-browserbrowserextensionchromeedgenbrowserpupnative-messagingcredentialschip-fetcher
Overview Files Skills Discover Packages Releases Dependencies Issues7 Breadcrumbs Pull Requests1 Activity
Closed bug report

readiness reports ready:true on an unroutable pending-* connection (drives then fail 'not connected'; no-profile route hangs 30s)

John Lauer · 2mo ago ·closed by John Lauer

nbrowser_readiness reports ready:true off a pending-* connection that NO drive verb can actually use — the user is told "ready", then every drive fails "extension not connected".

Found verifying issue #22 on a second machine (ConfRoomROG, ab 2.0.59, nb 0.3.4, ext 0.2.0). Sequence, all within seconds:

nbrowser_readiness  -> ready:true, state:"ready", profiles:["pending-4"],
                       extensionVersions:{"pending-4":"unknown"},
                       hint: "nbe is connected (1 profile(s)) and current (v0.2.0); drive it with nbrowser_open_window"
nbrowser_demo {profile:"pending-4"}  -> "native browser extension not connected"  (43ms)
nbrowser_open_window {no profile}    -> Request timed out (30s)
nbrowser_resolve_profiles            -> readiness now ready:false, profiles:[]

So pending-* (an extension socket that connected but whose profile identity has not resolved to a real Chrome profile) counts toward readiness, but targetConn cannot route to it. Three separate bad outcomes from one root:

  1. Readiness lies. ready:true + "drive it with nbrowser_open_window" is exactly the wrong instruction. For a public release this is the worst kind of bug: the probe we tell every AI to trust as the cold-start check is confidently wrong.
  2. Failure modes are inconsistent — with an explicit profile it fails fast and correctly (43ms); with no profile it hangs the full 30s and the caller learns nothing.
  3. resolve_profiles doesn't repair it, it just drops the connection entirely (ready:false, profiles:[]) — so there is no recovery path short of the SW re-dialing.

Proposed fix: ready must mean drivable. Exclude pending-* from the readiness profile list and from ready; when the only connection(s) are pending, report state:"resolving" with a hint that the extension has dialed but its profile identity has not resolved yet (and that nbrowser_wake_profile / opening any window in that profile completes it). Separately, routing to a pending/unroutable connection should fail fast with extension_not_connected, never hang for the timeout.

Related: 0.2.6 already fixed a neighbouring pending-* bug (sessions pinned to a pending pseudo-profile were poisoned forever). Same root cause family — pending-* is being treated as a real profile identity in more places than it should be.

Battery note: the daily verb battery hard-requires a resolvable profile during warm-up, so it would have gone red on this box rather than silently testing nothing.

1 Reply

John Lauer · 2mo ago

Closing this — filing a ticket against my own code was the wrong call; I'm the nb-bridge build thread, so this is a fix, not a report. Done in 0.3.5 (+ follow-ups through 0.3.7), verified on both AdomLapper and ConfRoomROG:

  • ready now means DRIVABLE. pending-* connections (extension socket up, profile identity unresolved) no longer count toward ready and are reported separately as pendingProfiles with state:"resolving" and a hint naming the fix (nbrowser_wake_profile, or just poll until ready). No more "ready:true → every drive fails".
  • Unroutable now fails fast, explicitly. Routing to a pending-only connection returns errorCode:"extension_resolving" in ~29ms instead of hanging the caller for 30s with nothing learned (measured: 29ms vs the old 30,000ms).
  • Related hangs fixed while in here: composite verbs referenced an out-of-scope args alias, so a ReferenceError inside an async IIFE never resolved the promise (this silently broke nbrowser_uninstall too); added a guarded() wrapper so any throw in a composite becomes a fast readable error instead of a hang. nbrowser_state and nbrowser_demo now bound their optional capture and degrade to state-only rather than blocking.
  • nbrowser_demo self-heals a sleeping SW (wake + retry once), so the web-control demo works cold: verified 15.5s cold-start → hwnd:5377454 + a 323KB inline screenshot, and 2.0s warm.

Going forward I'll fix nb bugs in-thread and only file against nb when something genuinely needs another party's decision.

John Lauer closed this · 2mo ago

Log in to reply.