{"version":"2.1.280","anchor":"stalled-state-added-to-remoteplumbing-status-tracking","canonical_anchor":"stalled-state-added-to-remoteplumbing-status-tracking","heading":"Status tracking gains an 'open' field for running vs stalled vs unknown state","tier":"internal","area":"Remote Control","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/stalled-state-added-to-remoteplumbing-status-tracking","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### Status tracking gains an 'open' field for running vs stalled vs unknown state\n\nTask and remote status responses now include an 'open' field marking whether an operation is stalled, still running, or of unknown delivery\n\n**Unclear.** It's unclear which user-facing feature consumes this 'stalled' status or how it's surfaced.\n\n**What**\n\nStatus objects for timed or capped remote\/background operations now include a new `open` field:\n\n- A status object used for tracking timed\/capped operations now sets `open: \"stalled\"` when a request isn't a probe and hasn't been 'taken back,' in addition to its existing taken-back-based branching.\n\n- A `still_running` status response now includes `open` set to either `\"still_running\"` (when the operation is literally still running) or `\"delivery_unknown\"` otherwise, alongside the existing code\/message\/host fields.\n\n**Why**\n\nThis gives a clearer, explicit signal for distinguishing an operation that's genuinely still running from one that's stalled or whose delivery status just isn't known, instead of leaving that ambiguous.\n\n- Area: Remote Control\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}