feat(commands): bind a job to the thread it was started in #676

Merged

coilyco-ops merged 1 commit from coilyco-ops/bind-a-job-to-its-thread into main

2026-08-13 18:34:37 +00:00

AGit

coilyco-ops commented

2026-08-13 18:33:32 +00:00

Member

closes #620 - the id-less job command fallback could never resolve because nothing wrote the binding it reads. Binding an existing thread needed no decision, only creating one does.

coilyco-ops added 1 commit

2026-08-13 18:33:32 +00:00

feat(commands): bind a job to the thread it was started in

ci / image-build (pull_request) Successful in 25s

Details

ci / test (pull_request) Successful in 39s

Details

ci / publish-echo-image (pull_request) Has been skipped

Details

ci / publish-observed (pull_request) Has been skipped

Details

f7c423d89a

job-status and job-cancel take an optional job id and fall back to the thread's
binding, so a follow-up inside the thread repeats nothing. That fallback could
never resolve. BindJobToThread is the only writer of Origin.ThreadID and nothing
called it, so an id-less command always reported no referent.

I filed sirens-echo#620 saying this needed a product decision, because binding
requires either creating a thread per job or binding an existing one. Only the
first is a decision. The second was already free and I did not check.

Discord treats a thread as a channel, so a command run inside a thread already
arrives with that thread as its channel id. The job knew its thread the whole
time and nothing recorded it.

Only a thread binds. Binding an ordinary channel would make it resolve to one
arbitrary job of however many were started there, which is worse than no
binding.

Best effort. BindJobToThread refuses a thread already bound to another job,
which is the singularity the commands doc states rather than a fault, so it is
logged and the job still submits.

Quail's threadbindingdoc test caught the docs the moment the caller appeared,
which is exactly what it was written for. Both are updated: the threads doc no
longer says unwired, and the commands doc now states the two limits rather than
that nothing binds at all.

What stays open is whether a job gets its own thread, created for it. Nothing
opens one, so a job started in a channel still has no referent. That is the
decision, and it is Kai's.

closes #620

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

2026-08-13 18:33:32 +00:00

coilyco-ops referenced this pull request

2026-08-13 18:33:54 +00:00

Four documented capabilities have no production caller, and one of them makes a shipped Discord command unable to succeed #620

coilyco-ops merged commit 0bc5132528 into main

2026-08-13 18:34:37 +00:00

coilyco-ops referenced this pull request from a commit

2026-08-13 18:34:39 +00:00

Merge pull request 'feat(commands): bind a job to the thread it was started in' (#676) from coilyco-ops/bind-a-job-to-its-thread into main

coilyco-ops referenced this pull request

2026-08-13 19:14:46 +00:00