@teamvibe/poller 0.6.2 → 0.7.0

package/dist/poller.js

@@ -12,7 +12,7 @@ import { initAuth, stopRefresh, getPollerId } from './auth-provider.js';
 import { registerBrain, startMaintenanceLoop, stopMaintenanceLoop } from './maintenance-cron.js';
 import { startEventQueue, stopEventQueue, flush as flushEventQueue, emitEvent, emitError } from './event-queue.js';
 import { startMetricsCron, stopMetricsCron } from './metrics/scheduler.js';
-import { writeMessage, pickNextMessage, markProcessed, markFailed, hasUnprocessed } from './inbox-manager.js';
+import { writeMessage, pickNextMessage, markProcessed, markFailed, hasUnprocessed, requeueMessage } from './inbox-manager.js';
 import { startInboxWatcher, stopInboxWatcher } from './inbox-watcher.js';
 import { Cron } from 'croner';
 import { isControlMessage, handleControlMessage } from './control-handler.js';
@@ -132,6 +132,57 @@ const activeLoops = new Set();
 export function isInboxLoopActive(threadId) {
     return activeLoops.has(threadId);
 }
+// Exported for testing (teamvibe.ai#32). SIGTERM (143) / SIGKILL (137) exit
+// codes are the classic 128+signal convention for "the poller itself killed
+// this process on purpose" (timeout, idle, network, zombie, or — as of #32 —
+// a compaction-ceiling watchdog kill). Historically all of these set
+// `killedByPoller` via the same `proc.kill('SIGTERM')` path in
+// claude-spawner.ts and were observed to surface as 143/137 here.
+//
+// PR#308 round-2 review (teamvibe.ai#73): this exit-code convention is
+// fragile on its own — the Claude CLI can legitimately exit 143 for
+// unrelated reasons, and #73's move to group-kill (`process.kill(-pid, ...)`
+// instead of a direct `proc.kill()`) means a signal-terminated close now
+// reports `code: null` with a separate `signal` field (verified empirically
+// against a synthetic detached child in this repo's environment — Node's
+// `close` event reports `code: null` for any signal-terminated process,
+// group-killed or not). Kept as a defensive fallback only — see
+// isPollerInitiatedFailure() below, which is what callers should actually use.
+export function isIntentionalKillExitCode(exitCode) {
+    return exitCode === 143 || exitCode === 137;
+}
+// The actual retry-classification signal (PR#308 round-2 review item 1):
+// `killedByPoller` is the purpose-built marker for "the poller killed this
+// process on purpose, not an application failure" (see SpawnResult /
+// classify-failed-iteration.ts) and is set on every poller-initiated kill
+// path this branch touches — timeout, idle watchdog, network watchdog,
+// zombie-kill, and (added by this fix) poller shutdown. Prefer it, and fall
+// back to the exit-code heuristic only when it's absent (e.g. hand-built
+// SpawnResult literals in older/unrelated call sites) so behavior doesn't
+// regress for anything not yet covered by the marker.
+export function isPollerInitiatedFailure(result) {
+    return Boolean(result.killedByPoller) || isIntentionalKillExitCode(result.exitCode);
+}
+// teamvibe.ai#284 (poller-brain#235): end-of-turn guard. A successful Claude
+// run can end its turn having only written plain assistant text — no
+// `mcp__slack__send_message` tool call — which the platform otherwise drops
+// silently (no error, no signal; see poller-brain#235's 4x-in-one-session
+// recurrence). Decides whether this run needs the deterministic fallback
+// delivery, and if so, what text to send.
+//
+// Pure/exported (mirrors classifyFailedIteration's pattern) so the gating
+// logic — "Slack context AND no send_message call AND non-empty trailing
+// text" — is unit-testable without mocking spawnClaudeCode or sendSlackMessage.
+// Deliberately does NOT fire on a failed run (result.success === false):
+// that path already has its own delivery via classifyFailedIteration +
+// sendSlackMessage/sendSlackError, and firing here too would double-deliver.
+export function endOfTurnFallbackText(hasSlackContext, result) {
+    if (!hasSlackContext || !result.success || result.sawSendMessageCall) {
+        return undefined;
+    }
+    const text = result.lastPlainTextContent?.trim();
+    return text ? text : undefined;
+}
 export async function runInboxLoop(threadId, kbPath, queueMessage, sessionLog) {
     if (activeLoops.has(threadId)) {
         sessionLog.info(`Loop already running for thread ${threadId}, skipping`);
@@ -160,7 +211,25 @@ export async function runInboxLoop(threadId, kbPath, queueMessage, sessionLog) {
             activeLocks.set(threadId, lockToken);
         }
         let currentSessionId = session.session_id || undefined;
-        while (true) {
+        // PR#308 round-3 review (teamvibe.ai#73): `shuttingDown` (declared below,
+        // referenced here via the same forward-reference pattern already used by
+        // pollLoop()'s `while (!shuttingDown)`) gates every new iteration of this
+        // loop, not just the retry-classification decision inside it. Without
+        // this, a message killed with `killedByPoller: 'shutdown'` (added by this
+        // branch) falls into the same "poller-initiated, retry immediately, no
+        // backoff" bucket as timeout/idle/network/zombie (see
+        // isPollerInitiatedFailure() below) — correctly skipping markProcessed/
+        // markFailed so the message stays unprocessed for a future boot, but with
+        // nothing to stop the loop from immediately calling pickNextMessage()
+        // again and spawning a NEW `claude` process for that same message, even
+        // though killAllActiveProcesses() (shutdown()'s first step) already ran.
+        // Gating the loop *condition* itself (rather than special-casing
+        // 'shutdown' inside the retry decision) closes this for every
+        // killedByPoller reason uniformly, and — unlike a `break` — falls through
+        // to the exact same post-loop cleanup (releaseSessionLock etc., below)
+        // that the existing `if (!message) break` / `if (!hasUnprocessed(...))
+        // break` exits already use, so lock release is unaffected.
+        while (!shuttingDown) {
             const message = pickNextMessage(kbPath, threadId);
             if (!message) {
                 sessionLog.info(`[Loop] No more messages for thread ${threadId}`);
@@ -177,6 +246,7 @@ export async function runInboxLoop(threadId, kbPath, queueMessage, sessionLog) {
                 : undefined;
             let succeeded = false;
             let lastExitCode = null;
+            let lastKilledByPoller;
             try {
                 // Reconstruct queue message from stored inbox data
                 const storedData = JSON.parse(message.content);
@@ -227,6 +297,28 @@ export async function runInboxLoop(threadId, kbPath, queueMessage, sessionLog) {
                             modelSource: result.modelSource,
                         });
                     }
+                    // teamvibe.ai#284 (poller-brain#235): end-of-turn guard. A
+                    // successful run that never called send_message but left trailing
+                    // plain text would otherwise vanish silently — deliver it via the
+                    // same sendSlackMessage() helper used for the failure-path neutral
+                    // notices, and emit a warning-level event so the near-miss is
+                    // visible (today session.completed looks identical whether or not
+                    // this fired).
+                    const fallbackText = endOfTurnFallbackText(hasSlackContext, result);
+                    if (fallbackText) {
+                        sessionLog.warn(`[Loop] Iteration #${iteration}: no send_message call detected, delivering trailing assistant text via fallback`);
+                        try {
+                            await sendSlackMessage(queueMessage, fallbackText);
+                        }
+                        catch (err) {
+                            sessionLog.error(`[Loop] End-of-turn fallback delivery failed: ${err instanceof Error ? err.message : err}`);
+                        }
+                        emitError('session', 'End-of-turn guard: delivered assistant text via fallback (no send_message tool call detected)', {
+                            severity: 'warn',
+                            channelId: queueMessage.teamvibe.channelId,
+                            context: { threadId: queueMessage.thread_id },
+                        });
+                    }
                     if (queueMessage.teamvibe.brain?.brainId) {
                         await pushBrainChanges(kbPath, queueMessage.teamvibe.brain.brainId, queueMessage.teamvibe.workspaceId);
                     }
@@ -234,6 +326,7 @@ export async function runInboxLoop(threadId, kbPath, queueMessage, sessionLog) {
                 }
                 else {
                     lastExitCode = result.exitCode;
+                    lastKilledByPoller = result.killedByPoller;
                     sessionLog.error(`[Loop] Claude failed iteration #${iteration}: ${result.error}`);
                     if (hasSlackContext) {
                         const decision = classifyFailedIteration(result);
@@ -255,8 +348,19 @@ export async function runInboxLoop(threadId, kbPath, queueMessage, sessionLog) {
                 markProcessed(kbPath, threadId, message.filename);
             }
             else {
-                // SIGTERM (143) or SIGKILL (137) = intentional kill → retry immediately, no backoff
-                const isKilledSignal = lastExitCode === 143 || lastExitCode === 137;
+                // Poller-initiated kill (timeout/idle/network/zombie/shutdown, via
+                // `killedByPoller`, or the legacy 143/137 exit-code fallback) → never
+                // counts as an application failure, so markFailed/backoff is skipped
+                // below regardless of reason. For timeout/idle/network/zombie this
+                // really does mean "retry immediately" — the `while (!shuttingDown)`
+                // condition above lets the loop come straight back around. For
+                // 'shutdown' specifically, `shuttingDown` is already true by the time
+                // this reads, so the loop condition above stops it from actually
+                // retrying inline — instead the branch below requeues the message
+                // from processing/ back to new/ (PR#308 round-5) so a future boot's
+                // inbox watcher finds it. See isPollerInitiatedFailure() and the
+                // loop-condition comment above.
+                const isKilledSignal = isPollerInitiatedFailure({ exitCode: lastExitCode, killedByPoller: lastKilledByPoller });
                 if (!isKilledSignal) {
                     const failures = (failureCounts.get(message.filename) || 0) + 1;
                     failureCounts.set(message.filename, failures);
@@ -271,6 +375,43 @@ export async function runInboxLoop(threadId, kbPath, queueMessage, sessionLog) {
                         await sleep(backoffMs);
                     }
                 }
+                else if (lastKilledByPoller === 'shutdown') {
+                    // PR#308 round-5 review (teamvibe.ai#73): pickNextMessage() moves a
+                    // message's file to processing/ as soon as it's picked up, not once
+                    // it completes — so a message killed here by shutdown is left
+                    // sitting in processing/, not new/. The watcher's wake condition
+                    // (hasNewMessage(), inbox-watcher.ts) only scans new/, so nothing
+                    // would start a fresh runInboxLoop() for this thread on next boot.
+                    // Requeue it back to new/ so a future boot's watcher scan actually
+                    // finds it — this is what makes "your message is saved" (the
+                    // shutdown notice text below, classify-failed-iteration.ts)
+                    // literally true. It does NOT make resumption automatic: the
+                    // watcher's checkInboxForNewSessions() (inbox-watcher.ts) only
+                    // scans brains already in the in-memory trackedBrains map, which
+                    // is empty after a fresh poller start until some SQS activity for
+                    // this brain re-registers it (see teamvibe.ai#310) — hence the
+                    // notice text also naming "next message or scheduled run" rather
+                    // than claiming automatic resumption.
+                    //
+                    // Scoped to 'shutdown' only, deliberately not the other four
+                    // poller-initiated reasons (timeout/idle/network/zombie) — those
+                    // retry immediately within this same still-running loop iteration
+                    // (the `while (!shuttingDown)` condition above lets it come
+                    // straight back around), so the existing processing/
+                    // crash-recovery branch inside pickNextMessage() already covers
+                    // them; requeueing those too would be redundant and could
+                    // double-process.
+                    //
+                    // Safe against waking a brand-new loop for this thread before this
+                    // poller process actually exits: stopInboxWatcher() runs earlier in
+                    // shutdown() (poller.ts), BEFORE killAllActiveProcesses() (whose
+                    // completion is what unblocks this iteration and reaches this
+                    // branch) — and stopInboxWatcher() closes the real fs.watch
+                    // handlers themselves (inbox-watcher.ts stopInboxWatcher(), not
+                    // just an interval/poll timer), so by the time this requeue runs,
+                    // nothing is watching new/ to react to the file reappearing there.
+                    requeueMessage(kbPath, threadId, message.filename);
+                }
             }
             if (!hasUnprocessed(kbPath, threadId)) {
                 break;
@@ -515,6 +656,19 @@ function sleep(ms) {
 }
 // Graceful shutdown
 let shuttingDown = false;
+// Exported for testing only (PR#308 round-3 review item 1). `shuttingDown`
+// has no other external mutator — production code only ever flips it via
+// the real shutdown() below, which also runs killAllActiveProcesses(),
+// releaseAllActiveLocks(), the drain loop, and process.exit(). This setter
+// lets a test put runInboxLoop's `while (!shuttingDown)` gate into the
+// "shutdown in progress" state directly (mirroring the exact race
+// shutdown() itself creates — killAllActiveProcesses() kills the in-flight
+// spawn while its promise is still pending) without invoking any of those
+// real side effects. Same pattern as __resetCronTelemetryForTest /
+// __resetTrackedBrainsForTest elsewhere in this package.
+export function __setShuttingDownForTest(value) {
+    shuttingDown = value;
+}
 async function shutdown(signal, exitCode = 0) {
     if (shuttingDown)
         return;

package/dist/types.d.ts

@@ -19,6 +19,12 @@ export interface TeamVibeQueueMessage {
         filename: string;
         mimetype: string;
     }>;
+    inlineImages?: Array<{
+        mediaType: string;
+        data?: string;
+        url?: string;
+        expiresAt?: string;
+    }>;
     response_context: {
         slack?: {
             channel: string;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@teamvibe/poller",
-  "version": "0.6.2",
+  "version": "0.7.0",
   "type": "module",
   "main": "./dist/index.js",
   "bin": {