bluebut#60done

/home/philip/Documents/GitHub/bluebut-issue-60
fix/issue-60
---MRs---
No open merge requests match your search in devdashco/bluebut.

(Bash completed with no output)

1:// routes/jobs — the jobs resource. Thin: validate against the contract, call the
2:// queue engine, validate out. No domain logic here (it lives in server/runs/*).
3:import { Hono } from 'hono'
4:import { z } from 'zod'
5:import { streamSSE } from 'hono/streaming'
6:import { zValidator } from '@hono/zod-validator'
7:import { EnqueueRequest } from '../contract/job.ts'
8:import { catalogSummary } from '../runs/catalog.ts'
9:import { enqueue, enqueueRaw, getJob, listJobs, isLedgerTerminal, okForStatus } from '../runs/queue.ts'
10:import { subscribe } from '../runs/step-stream.ts'
11:
12:export const jobs = new Hono()
13:
14:// The catalog IS the API surface — no dir scan, no convention-guessing.
15:jobs.get('/verbs', (c) => c.json({ verbs: catalogSummary() }))
16:
17:// Enqueue. Envelope validated by zValidator; the verb's own input schema is
18:// validated inside enqueue(). The app.ts onError classifies by TYPE: an unknown
19:// verb throws ValidationError → 400 `unknown_verb`; bad args throw a ZodError →
20:// 422 `invalid_input` with structured issues.
21:jobs.post('/', zValidator('json', EnqueueRequest), async (c) => {
22:  const { verb, input } = c.req.valid('json')
23:  return c.json(await enqueue(verb, input), 202)
24:})
25:
26:// epic #6 cutover: RAW enqueue — the durable-queue twin of the legacy POST /exec[/stream].
27:// The UI's runCli() speaks argv, not typed input, so this carries (site, cmd, args) verbatim
28:// onto the run row (input._raw) for the worker to spawn IDENTICALLY to the old inline /exec.
29:// The UI threads its own job_id so its job identity is unchanged; batch_id groups the run.
30:const ExecRequest = z.object({
31:  site: z.string(),
32:  cmd: z.string(),
33:  args: z.array(z.string()).default([]),
34:  job_id: z.string().optional(),
35:  batch_id: z.string().optional(),
36:})
37:jobs.post('/exec', zValidator('json', ExecRequest), async (c) => {
38:  const { site, cmd, args, job_id, batch_id } = c.req.valid('json')
39:  return c.json(await enqueueRaw(site, cmd, args, { job_id, batch_id }), 202)
40:})
41:
42:jobs.get('/', async (c) => {
43:  const n = Number(c.req.query('limit'))
44:  const limit = Number.isFinite(n) && n > 0 ? Math.min(n, 500) : 50   // NaN/negatives → default, cap at 500
45:  return c.json({ jobs: await listJobs({ limit }) })
46:})
47:
48:jobs.get('/:id', async (c) => {
49:  const job = await getJob(c.req.param('id'))
50:  return job ? c.json(job) : c.json({ error: 'not_found' }, 404)
51:})
52:
53:// Live status stream. Slice 1 polls the ledger until terminal; step-level events
54:// ride the runner's channel in a later slice.
55:jobs.get('/:id/events', (c) => streamSSE(c, async (stream) => {
56:  const id = c.req.param('id')
57:  // epic #6: tail the worker's live step-log lines (job-stream tap, same process) so the
58:  // dashboard shows per-step progress — the durable queue SSE otherwise carries only
59:  // status/result frames (the worker runs the runner out-of-band, no child to tee). Bare
60:  // `data:` frames (no event name) render as progress lines in ui/src/api/jobs.ts (onLine).

9:import { enqueue, enqueueRaw, getJob, listJobs, isLedgerTerminal, okForStatus } from '../runs/queue.ts'
26:// epic #6 cutover: RAW enqueue — the durable-queue twin of the legacy POST /exec[/stream].
28:// onto the run row (input._raw) for the worker to spawn IDENTICALLY to the old inline /exec.
30:const ExecRequest = z.object({
37:jobs.post('/exec', zValidator('json', ExecRequest), async (c) => {
39:  return c.json(await enqueueRaw(site, cmd, args, { job_id, batch_id }), 202)
78:        // (ui/src/api/jobs.ts, off /exec/stream → this stream) can resolve its

ugrep: warning: server/jobs/queue.ts: No such file or directory

84:// HTTP-200 `[ERROR] legacy /exec disabled` body with no [RESULT] line → "no RESULT
86:// deploy. Repointed here: enqueue a RAW send-message job (POST /api/queue/jobs/exec),
100:async function sendDm(account, peer, text, jobId) {
102:  const enq = await fetch(`${QUEUE}/jobs/exec`, {
105:    body: JSON.stringify({ site: 'messenger', cmd: 'send-message', args: ['--account', account, '--to', String(peer), '--text', text], job_id: jobId }),
241:      'select=id,action,intent,peer_fb_id,email,subject,body,geo_kommun,kommun,source_kind,source_ref,posted_at,created_at,profile_id'];
340:              notifyTelegram([`📧 Email · ${row.email} · ${row.subject || '(inget ämne)'}`, ...trace, '—', String(row.body || '').slice(0, 200)].join('\n'));
406:        const r = await sendDm(account, row.peer_fb_id, row.body, childJobId);
460:        // #92 item 3 — a throw here (sendDm's /exec/stream fetch timing out/aborting is

81: *  `priority` (claim order). All optional; omitting them = legacy FIFO immediate-claim. */
82:export interface EnqueueOpts {
85:  priority?: number            // higher = claimed first (default 0)
92:  opts: EnqueueOpts = {},
113:    priority: opts.priority ?? 0,
129:/** enqueueRaw — enqueue an arbitrary (site, cmd, argv) job WITHOUT the typed-verb
136:export async function enqueueRaw(
140:  opts: EnqueueOpts & { job_id?: string; account?: string | null } = {},
154:    priority: opts.priority ?? 0,

// terminal poll (e.g. a stuck per-account claim lock) returns a transient verdict so
// the row is RELEASED to re-drain, never stranded or double-sent.
async function sendDm(account, peer, text, jobId) {
  const auth = API_TOKEN ? { authorization: `Bearer ${API_TOKEN}` } : {};
  const enq = await fetch(`${QUEUE}/jobs/exec`, {
    method: 'POST',
    headers: { 'content-type': 'application/json', ...auth },
    body: JSON.stringify({ site: 'messenger', cmd: 'send-message', args: ['--account', account, '--to', String(peer), '--text', text], job_id: jobId }),
    signal: AbortSignal.timeout(30000),
  });
  if (!enq.ok) return { ok: false, status: 'error', aborted_reason: `queue enqueue failed (HTTP ${enq.status})` };
  // Poll the run ledger to terminal. Worker claims within ~1 poll; the send itself is a
  // few seconds (browser-free daemon POST). Cap the wait ~170s (under the caller's own
  // guards); the per-account claim lock serialises same-account sends — expected, since
  // outreach already paces per account.

(Bash completed with no output)

The file /home/philip/Documents/GitHub/bluebut-issue-60/server/routes/jobs.ts has been updated successfully. (file state is current in your context — no need to Read it back)

The file /home/philip/Documents/GitHub/bluebut-issue-60/messenger/jobs/outreach-send.js has been updated successfully. (file state is current in your context — no need to Read it back)

committed

direct push to main is blocked - open a merge request (glab mr create).

8abe7420 fix(queue): high-priority send-message children so outreach-send parents don't self-deadlock (#60)
2f3ebb18 fix(mcp): point every bluebut MCP server at http — no more per-session forks (#61)
b30ae657 feat(mcp): host the 4 OpenAPI MCP surfaces over http instead of per-session stdio (#61)
---
## fix/issue-60...origin/main [ahead 1]

=== branch vs origin/main ===
8abe7420 fix(queue): high-priority send-message children so outreach-send parents don't self-deadlock (#60)
=== does origin/main already have the fix commit? ===
=== current diff of the fix in HEAD ===
commit 8abe742072971ad6cb51c2778c62d4184a089186
Author: philip (pbox) <philip@devdash.co>
Date:   Sat Jul 25 13:51:39 2026 +0200

    fix(queue): high-priority send-message children so outreach-send parents don't self-deadlock (#60)
    
    outreach-send parents hold one of the worker's 3 slots while synchronously
    polling their send-message child. With a backlog, all 3 slots fill with parents
    and no slot claims a child — the parents time out at 170s and release leads
    without sending. Enqueue the child at priority 100 so a freeing slot always
    claims the terminal delivery step ahead of another parent.
    
    - server/routes/jobs.ts: ExecRequest accepts optional priority, passed to enqueueRaw
    - messenger/jobs/outreach-send.js: sendDm enqueues send-message at priority 100
    
    Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

 messenger/jobs/outreach-send.js | 5 ++++-
 server/routes/jobs.ts           | 9 +++++++--
 2 files changed, 11 insertions(+), 3 deletions(-)

remote: 
remote: To create a merge request for fix/issue-60, visit:        
remote:   https://gitlab.hostbun.cc/devdashco/bluebut/-/merge_requests/new?merge_request%5Bsource_branch%5D=fix%2Fissue-60        
remote: 
To https://gitlab.hostbun.cc/devdashco/bluebut.git
 * [new branch]        fix/issue-60 -> fix/issue-60

Creating merge request for fix/issue-60 into main in devdashco/bluebut

https://gitlab.hostbun.cc/devdashco/bluebut/-/merge_requests/18

ERROR  
          
  All attempts fail:                                                                                                  
  #1: PUT https://gitlab.hostbun.cc/api/v4/projects/devdashco%2Fbluebut/merge_requests/18/merge: 400 {message: SHA    
  must be provided when merging}.

! No pipeline running on fix/issue-60
✓ Merged!
https://gitlab.hostbun.cc/devdashco/bluebut/-/merge_requests/18

https://gitlab.hostbun.cc/devdashco/bluebut/-/work_items/60#note_890

no result shipped