Deferred from PR #1302 (head cdf51d2a5517e3214cf2e60cd8a41bcc95a742c4), review rounds 1 and 2, finding 2.
Severity: Low (deferred hardening; not a defect PR #1302 ships).
Where: hypaware-core/plugins-workspace/github/src/tick.js:28, the await runtime.observedRepos.list() inside runCaptureTick.
Evidence and behavior: PR #1302 fixed the all_visible half of this shape: resolveRepos was awaited outside the per-repo try/catch, so an enumeration failure escaped captureRepos and aborted the whole tick instead of one repo. The session_repos half is unchanged. When runtime.config.inventory === 'session_repos', runCaptureTick awaits runtime.observedRepos.list() before the guarded capture loop, so a throw there propagates out of runCaptureTick into the tick() catch in source.js and the tick records github.poll_tick_failed having captured nothing.
Why deferral is safe: This is pre-existing behavior on master, not something PR #1302 introduced. The PR does not touch tick.js (git diff --stat origin/master...HEAD covers only capture.js, commands.js, and two test files). The call is a local cache read rather than a network call, so it is far less failure-prone than the listViewerRepos() path that motivated #1298. When it does fail the outcome is attributable (github.poll_tick_failed plus lastError), it retries on the ordinary cadence, and backlogPending survives the catch, so no durable work is lost or cleared. It is explicitly outside issue #1298's acceptance condition.
Acceptance: With inventory: 'session_repos' configured and runtime.observedRepos.list() made to throw, runCaptureTick resolves rather than throwing: the failure is recorded in the returned errors array and logged with its error_kind, the tick completes, and pending reflects durable saved work rather than being cleared. Covered by a test alongside the all_visible case in test/plugins/github-capture.test.js.
Deferred from PR #1302 (head
cdf51d2a5517e3214cf2e60cd8a41bcc95a742c4), review rounds 1 and 2, finding 2.Severity: Low (deferred hardening; not a defect PR #1302 ships).
Where:
hypaware-core/plugins-workspace/github/src/tick.js:28, theawait runtime.observedRepos.list()insiderunCaptureTick.Evidence and behavior: PR #1302 fixed the
all_visiblehalf of this shape:resolveReposwas awaited outside the per-repotry/catch, so an enumeration failure escapedcaptureReposand aborted the whole tick instead of one repo. Thesession_reposhalf is unchanged. Whenruntime.config.inventory === 'session_repos',runCaptureTickawaitsruntime.observedRepos.list()before the guarded capture loop, so a throw there propagates out ofrunCaptureTickinto thetick()catch insource.jsand the tick recordsgithub.poll_tick_failedhaving captured nothing.Why deferral is safe: This is pre-existing behavior on master, not something PR #1302 introduced. The PR does not touch
tick.js(git diff --stat origin/master...HEADcovers onlycapture.js,commands.js, and two test files). The call is a local cache read rather than a network call, so it is far less failure-prone than thelistViewerRepos()path that motivated #1298. When it does fail the outcome is attributable (github.poll_tick_failedpluslastError), it retries on the ordinary cadence, andbacklogPendingsurvives the catch, so no durable work is lost or cleared. It is explicitly outside issue #1298's acceptance condition.Acceptance: With
inventory: 'session_repos'configured andruntime.observedRepos.list()made to throw,runCaptureTickresolves rather than throwing: the failure is recorded in the returnederrorsarray and logged with itserror_kind, the tick completes, andpendingreflects durable saved work rather than being cleared. Covered by a test alongside theall_visiblecase intest/plugins/github-capture.test.js.