The kernel's sink readers still take handle.plugin, handle.kind and handle.config off a live handle, so an owner's accessor ends the daemon tick that PR #2057 left it beside

Open
  • Is something wrong?
#2,059 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
javascript, node.js
Domain
backend, devtools

Research direction

Start with the sink registry in src/core/registry/sinks.js and the reader paths in src/core/daemon/runtime.js, src/core/daemon/status.js, and src/core/sinks/driver.js. Then read test/core/sink-hostile-instance-name.test.js, which is identified as the natural home for the plugin, kind, and config accessor cases. Done means those readers use registry-record values and hostile accessors no longer abort status collection or the daemon tick, nor prevent an honest neighboring sink from exporting.

Written by the indexing model from the issue text.

Description

Feature or issue

PR #2057 closed the handle.instanceName half of the reader problem #1976 names: hyp status, the daemon's per-tick status.sinks write and the sink driver's due check now take the instance name from the registry's own record instead of off the live handle. The sibling properties read on the very same lines were deliberately left, and each one reproduces the identical outage.

A sink handle is a live object its owner still holds through ctx.sinks.get (LLP-documented at src/core/runtime/activation.js, the get/list half of #1961), so every one of its properties is replaceable with an accessor of the owner's.

Verified against 60f41ac5 (PR #2057's head), with two live instances materialized through the owner's real activation context and a throwing accessor installed on the one that sorts first:

  • src/core/daemon/runtime.js:1876-1881 reads handle.plugin and handle.kind one line after the guarded name. collectSinkSnapshots threw boom from the owner for both. This is the serious one: the call at src/core/daemon/runtime.js:918 sits after the tick's .catch(...) at :912-917, the tick is driven by setInterval(() => { void runTick() }, ...) at :956, and there is no unhandledRejection handler anywhere in this repo (src/core/otlp/server.js:255 records exactly that). So the throw is an unhandled rejection and ends the daemon, once, on the first tick after the accessor is installed.
  • src/core/daemon/status.js:1851 reads handle.plugin and handle.kind on the same line as sinkInstanceName(handle). collectHypAwareStatus threw the same error. Nothing on that path catches, so hyp status still goes down whole.
  • src/core/sinks/driver.js:80 reads handle.config?.schedule immediately after the hardened name read and ahead of the due check. A throwing config accessor threw out of driver.tick, so the honest neighbour sorting behind the hostile instance never exported. handle.plugin is read again in the failure path at :326 and :286.

The fix PR #2057 established already has the shape this needs: the kernel knows all three facts at instantiate time (args.kind, the contribution plugin it resolved, and the config row it validated), so the module-level record in src/core/registry/sinks.js can carry them beside the name it already records, and the readers take them from there.

Out of scope here and worth their own pass: src/core/commands/sync.js, src/core/commands/sink.js and src/core/sinks/pending.js read handle.instanceName unguarded too, but those are user-invoked CLI commands that fail loudly at the terminal rather than silently in a daemon loop.

Reproduction

Install a throwing accessor on a live handle taken back through the owner's own ctx.sinks.get, then call collectSinkSnapshots:

Object.defineProperty(ctx.sinks.get('a-hostile'), 'plugin', {
  configurable: true,
  get() { throw new Error('boom from the owner') },
})
collectSinkSnapshots({ runtime, sinkSnapshots: new Map() }) // throws

test/core/sink-hostile-instance-name.test.js already stages exactly this for instanceName and is the natural home for the plugin, kind and config variants.

Triage addendum (PR #2097 at cd0d42d4ff03dc3c4e6439f8cef9dc6f43d76212): three findings from PR #2097's review land in this issue's class and are deferred here rather than duplicated.

  • Finding 2: the registry record PR #2097 introduces is a shallow copy ({ ...config }, src/core/registry/sinks.js:423/:525), so nested values stay shared with the owner's live object. Every current reader is typeof === 'string'-gated on top-level scalars, but a reader this issue converts to the record must not assume nested isolation: src/core/commands/sink.js:91 pulls config.maintenance, a nested object, and would share it by reference.
  • Finding 4: describeDestination's third branch (src/core/commands/sync.js) still reads handle.plugin live - it can mis-name or throw (loudly, at the terminal) but cannot hide a row, since its offMachine: null survives the plan filter. The record-widening this issue proposes is the fix: carry plugin beside instanceName and config and read it from the record.
  • Finding 5: src/core/sinks/driver.js:86 still reads handle.config?.schedule live (already named above), so the plan (recorded config) and the driver's due check (live config) can diverge - only in the benign direction: the plan over-states what leaves the machine.
Dominant language
JavaScript
Stars
11
Forks
0
Avg merge
2h 55m
Merged PRs (30d)
294

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from hyparam/hypaware

All issues in hyparam/hypaware

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.