instar 1.3.844 → 1.3.845
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/commands/server.d.ts.map +1 -1
- package/dist/commands/server.js +32 -0
- package/dist/commands/server.js.map +1 -1
- package/dist/monitoring/ResumeQueue.d.ts +6 -0
- package/dist/monitoring/ResumeQueue.d.ts.map +1 -1
- package/dist/monitoring/ResumeQueue.js +7 -2
- package/dist/monitoring/ResumeQueue.js.map +1 -1
- package/dist/monitoring/ResumeQueueDrainer.d.ts +4 -0
- package/dist/monitoring/ResumeQueueDrainer.d.ts.map +1 -1
- package/dist/monitoring/ResumeQueueDrainer.js +14 -0
- package/dist/monitoring/ResumeQueueDrainer.js.map +1 -1
- package/dist/server/routes.d.ts.map +1 -1
- package/dist/server/routes.js +38 -1
- package/dist/server/routes.js.map +1 -1
- package/dist/threadline/ListenerSessionManager.d.ts +26 -0
- package/dist/threadline/ListenerSessionManager.d.ts.map +1 -1
- package/dist/threadline/ListenerSessionManager.js +115 -1
- package/dist/threadline/ListenerSessionManager.js.map +1 -1
- package/dist/threadline/ThreadlineMCPServer.d.ts +2 -0
- package/dist/threadline/ThreadlineMCPServer.d.ts.map +1 -1
- package/dist/threadline/ThreadlineMCPServer.js +2 -0
- package/dist/threadline/ThreadlineMCPServer.js.map +1 -1
- package/dist/threadline/ThreadlineReapRecovery.d.ts +12 -0
- package/dist/threadline/ThreadlineReapRecovery.d.ts.map +1 -0
- package/dist/threadline/ThreadlineReapRecovery.js +60 -0
- package/dist/threadline/ThreadlineReapRecovery.js.map +1 -0
- package/dist/threadline/ThreadlineRouter.d.ts.map +1 -1
- package/dist/threadline/ThreadlineRouter.js +5 -2
- package/dist/threadline/ThreadlineRouter.js.map +1 -1
- package/dist/threadline/mcp-http-client.d.ts.map +1 -1
- package/dist/threadline/mcp-http-client.js +1 -0
- package/dist/threadline/mcp-http-client.js.map +1 -1
- package/package.json +1 -1
- package/src/data/builtin-manifest.json +46 -46
- package/upgrades/1.3.845.md +21 -0
- package/upgrades/side-effects/threadline-warm-reap-redrive.md +91 -0
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
# Upgrade Guide — vNEXT
|
|
2
|
+
|
|
3
|
+
<!-- assembled-by: assemble-next-md -->
|
|
4
|
+
<!-- bump: patch -->
|
|
5
|
+
|
|
6
|
+
## What Changed
|
|
7
|
+
|
|
8
|
+
An inbound Threadline message being processed by a warm reply worker is now retained in the durable resume queue when quota pressure reaps that worker. After pressure clears, Instar rechecks that the exact authenticated canonical inbound is still pending and routes it back through the existing Threadline router. Outbound replies now carry the exact inbound ID they answer, preventing both duplicate recovery and false settlement of interleaved messages.
|
|
9
|
+
|
|
10
|
+
## What to Tell Your User
|
|
11
|
+
|
|
12
|
+
Agent-to-agent conversations are more resilient under resource pressure: Instar can recover a reply that was interrupted when its warm worker was reclaimed.
|
|
13
|
+
|
|
14
|
+
## Summary of New Capabilities
|
|
15
|
+
|
|
16
|
+
- Durable recovery of an exact inbound Threadline message after quota reaping.
|
|
17
|
+
- Authenticated, drain-time duplicate suppression before the reply worker restarts.
|
|
18
|
+
|
|
19
|
+
## Evidence
|
|
20
|
+
|
|
21
|
+
Unit coverage verifies exact-message custody, HMAC tamper rejection, and outbound settlement. Integration coverage locks the production reap-to-queue wiring. E2E coverage reaps a warm worker mid-processing, drains after pressure clears, and observes one redrive.
|
|
@@ -0,0 +1,91 @@
|
|
|
1
|
+
# Side-Effects Review — Threadline warm-worker reap redrive
|
|
2
|
+
|
|
3
|
+
**Version / slug:** `threadline-warm-reap-redrive`
|
|
4
|
+
**Date:** 2026-07-16
|
|
5
|
+
**Author:** Instar-codey
|
|
6
|
+
**Second-pass reviewer:** independent reviewer agent
|
|
7
|
+
|
|
8
|
+
## Summary of the change
|
|
9
|
+
|
|
10
|
+
The shared `ResumeQueue` now accepts an exact Threadline recovery identity (`threadId` plus canonical inbound message ID) when quota pressure kills an unbound warm reply worker mid-turn. Threadline replies carry an HMAC-covered `inReplyTo`, so `server.ts` detects a provably unsettled authenticated inbound, the existing drainer retains all pressure and retry gates, and the recovery helper reconstructs only that exact message for the normal router after checking again that no authenticated correlated outbound settled it.
|
|
11
|
+
|
|
12
|
+
## Decision-point inventory
|
|
13
|
+
|
|
14
|
+
- `ResumeQueue.classifyEligibility` — modify — an unbound session has a resume path only when both Threadline identifiers exist.
|
|
15
|
+
- `server.ts sessionReaped` subscriber — modify — authenticated canonical inbound plus no later authenticated outbound produces the existing strong `pending-injection` evidence.
|
|
16
|
+
- `ResumeQueueDrainer.revalidate` — modify — exact Threadline state must remain pending immediately before redrive.
|
|
17
|
+
- `ThreadlineRouter.handleInboundMessage` — pass-through — the existing router still owns trust framing and spawn admission.
|
|
18
|
+
|
|
19
|
+
## 1. Over-block
|
|
20
|
+
|
|
21
|
+
Recovery is deliberately refused for malformed identifiers, missing/tampered canonical records, incomplete identity pairs, unavailable wiring, and messages already followed by an outbound. A legitimate message cannot be recovered if its local canonical file is unreadable; this is the safe failure direction because fabricating or replaying unverified content would be worse. Existing delivery remains unchanged.
|
|
22
|
+
|
|
23
|
+
## 2. Under-block
|
|
24
|
+
|
|
25
|
+
Outbound settlement requires the exact thread ID and `inReplyTo` message ID. Replies created without correlation metadata do not suppress recovery; this favors at-least-once completion over silently losing a reply. The prompt, MCP schema, localhost HTTP funnel, and canonical outbox all propagate the identity structurally for new reply workers.
|
|
26
|
+
|
|
27
|
+
## 3. Level-of-abstraction fit
|
|
28
|
+
|
|
29
|
+
Canonical lookup and HMAC verification belong in `ListenerSessionManager`, durable scheduling belongs in `ResumeQueue`, and contextual routing remains in `ThreadlineRouter`. No parallel reaper or restart controller was introduced. The low-level facts feed the established recovery authority and its quota, pressure, cap, retry, and resurrection gates.
|
|
30
|
+
|
|
31
|
+
## 4. Signal vs authority compliance
|
|
32
|
+
|
|
33
|
+
**Required reference:** [docs/signal-vs-authority.md](../../docs/signal-vs-authority.md)
|
|
34
|
+
|
|
35
|
+
- [x] No — this change produces a signal consumed by an existing smart gate.
|
|
36
|
+
|
|
37
|
+
The authenticated inbound and later-outbound absence are bounded signals. They do not kill, spawn, or send independently. The existing reaper remains kill authority, the drainer remains restart authority, and the router remains message-handling authority.
|
|
38
|
+
|
|
39
|
+
## 4b. Judgment-point check
|
|
40
|
+
|
|
41
|
+
No new static heuristic resolves competing semantic signals. Exact identity pairing, HMAC validity, and identifier syntax are enumerable integrity invariants. Thread-level settlement is intentionally conservative and feeds the existing recovery controller rather than claiming conversational judgment.
|
|
42
|
+
|
|
43
|
+
## 5. Interactions
|
|
44
|
+
|
|
45
|
+
- **Shadowing:** Threadline revalidation runs alongside the existing topic/job branches and cannot alter them.
|
|
46
|
+
- **Double-fire:** enqueue checks for an exact correlated outbound; drain checks again. A successful correlated send racing the reap therefore invalidates the queued replay before spawn.
|
|
47
|
+
- **Races:** a send after the second check but before cold spawn remains a narrow at-least-once boundary shared by distributed delivery systems. Stable per-thread queue keys, cold-spawn selection, and the router's normal conversation ownership reduce concurrent duplication.
|
|
48
|
+
- **Restart boundary:** ordinary reply claims are process-local, so a server restart after claim acquisition but before reply settlement reopens that same at-least-once window. Only the delivery-succeeded/outbox-append-failed edge is persisted as a durable failure claim, because it has positive evidence that replay risks a duplicate.
|
|
49
|
+
- **Feedback loops:** a failed spawn uses the existing bounded exponential backoff and resurrection cap; it does not recursively enqueue.
|
|
50
|
+
|
|
51
|
+
## 6. External surfaces
|
|
52
|
+
|
|
53
|
+
Other agents gain continuity: a reply that previously vanished can arrive after local pressure clears. Persistent state gains two non-secret identifiers in `resume-queue.json`; message bodies remain only in the existing canonical inbox. No operator action, new API, URL, Telegram flow, or external protocol is added.
|
|
54
|
+
|
|
55
|
+
## 6b. Operator-surface quality
|
|
56
|
+
|
|
57
|
+
No operator surface — not applicable.
|
|
58
|
+
|
|
59
|
+
## 7. Multi-machine posture
|
|
60
|
+
|
|
61
|
+
**Machine-local BY DESIGN:** quota reaping, the killed tmux worker, canonical inbox/outbox, and resume queue are truths of the machine that owned that warm session. Relay ownership and routing remain unchanged, so another machine does not independently redrive the same local worker. The feature emits no user-facing notice, creates no URL, and holds no topic-transfer state. Queue state expires or settles locally rather than following a Telegram topic.
|
|
62
|
+
|
|
63
|
+
## 8. Rollback cost
|
|
64
|
+
|
|
65
|
+
Hot-fix revert and patch release. Old binaries ignore the optional queue fields; no migration or agent-state repair is required. Existing queued Threadline entries would age out under the normal TTL after rollback.
|
|
66
|
+
|
|
67
|
+
## Conclusion
|
|
68
|
+
|
|
69
|
+
The design closes the discovered custody gap by reusing the one durable recovery controller, authenticating the recovery source, preserving all existing gates, and revalidating settlement at drain time. Focused unit, integration, and E2E tests cover integrity, production wiring, quota-reap persistence, and one redrive. Clear to ship after independent concurrence and the full push gate.
|
|
70
|
+
|
|
71
|
+
## Second-pass review
|
|
72
|
+
|
|
73
|
+
**Reviewer:** independent reviewer agent
|
|
74
|
+
**Independent read of the artifact:** concur
|
|
75
|
+
|
|
76
|
+
Concur with the review after two iterations added exact durable reply correlation, same-thread HMAC validation, a shared atomic send/redrive claim, structural omission rejection, and a durable append-failure claim that survives server restart.
|
|
77
|
+
|
|
78
|
+
## Evidence pointers
|
|
79
|
+
|
|
80
|
+
- `tests/unit/threadline-reap-recovery.test.ts`
|
|
81
|
+
- `tests/integration/threadline-reap-recovery-wiring.test.ts`
|
|
82
|
+
- `tests/e2e/threadline-reap-mid-processing.test.ts`
|
|
83
|
+
|
|
84
|
+
## Class-Closure Declaration (display-only mirror)
|
|
85
|
+
|
|
86
|
+
This modifies a self-triggered recovery path. The control-loop edge is quota reap → one stable per-thread queue entry → one router redrive. The steady-state bound is one open entry per thread with the existing queue TTL, retry ceiling, resurrection cap, and pressure/quota gates. The settling brake is an authenticated outbound whose `inReplyTo` exactly names the queued inbound, rechecked immediately before redrive.
|
|
87
|
+
|
|
88
|
+
- **`defectClass`** — `unbounded-self-action`
|
|
89
|
+
- **`closure`** — `guard`
|
|
90
|
+
- **`guardEvidence`** — `{ enforcementType: ratchet, citation: tests/e2e/threadline-reap-mid-processing.test.ts, howCaught: a quota-reaped warm Threadline worker must leave one exact durable recovery entry and produce exactly one redrive after pressure clears; tests/unit/self-action-convergence.test.ts ratchets the bounded-controller declaration }`
|
|
91
|
+
- **`gap`** — not applicable
|