{"version":"2.1.246","anchor":"device-bridge-shows-up-in-status-before-it-has-finished-conn","canonical_anchor":"device-bridge-shows-up-in-status-before-it-has-finished-conn","heading":"Device bridge shows up in \/status before it has finished connecting","tier":"use","area":"Remote Devices","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246\/e\/device-bridge-shows-up-in-status-before-it-has-finished-conn","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246","markdown":"### Device bridge shows up in \/status before it has finished connecting\n\n\/status now shows a paired machine as connecting rather than blank, and keeps retrying its tool list.\n\n**What**\n\nWhen you have a paired machine whose bridge has connected but not yet announced itself, `\/status` now says \"connecting\" or \"not_connected\" rather than showing nothing, and the tool listing keeps retrying until the machine is adopted instead of settling on an empty list.\n\n**Details**\n\n- Pending entries are held as provisional, marked as a stub, and stamped with the time they were first seen unconnected.\n- New telemetry on `tengu_remote_tool_targets`: `listed_empty` (with tool count, whether the list was truncated, marker count and stub flag) and `no_bridge_connection`, the latter carrying a per-entry reason such as `not_ccr_proxy_url`, `not_devices_upstream`, `routing_shape`, `needs_auth`, or `ingress_base_unset`.\n- Listing failures now record a reason, with timeouts classified separately from other errors.\n\n**Evidence**\n\n`no_bridge_connection`\n\n- Area: Remote Devices\n- Names: `\/status`\n- Tier: Use it now\n- Useful: 3\/5\n- Signal: 2\/5"}