stack/agents/darkwing/work/slice1-s3/probes.md

S3 probes, addendum B section 7 (Darkwing, row 38, #1520)

Run on 2026-10-08 against a scratch Vikunja: the runbook's Path B digest vikunja/vikunja@sha256:e2204a1c1c6a81e833c2b3a5442be182ca2335b54c2e7e37578cc3fe12a27cfc (v2.7.0), sqlite, bound to 127.0.0.1:34571, data dir under ~/darkwing-scratch/s3/vk/, wiped before each run. No probe touched the estate instance or tasks.mosaicstack.dev. Users and bots were created by the probe with random in-memory passwords. Each script refuses to write its output if any password or token appears in it.

Scripts and raw output live in ~/darkwing-scratch/s3/probes/: probe-s7.mjs (main), probe-s7b.mjs (label control, comments, cursor, shapes, rate limit), probe-s7c.mjs (date-filter bounds), probe-s7d.mjs and probe-s7e.mjs (bump timing), probe-s7f.mjs (token revoke, decision 68). Source reads are from the v2.7.0 tag.

L. Labels: what a bot can see

This was the critical probe. Result: with the runbook as written, a bot sees labels from projects that aren't shared with it. If the bots get a dedicated owner account, it sees none of them.

1. The runbook creates the bots from the owner's account. A pm bot shared only into mosaic-stack got the full list back from GET /labels: on-ms-task, on-launchpad-task, on-personal-task, owner-unattached. A search for launchpad returned the same list. The bot also attached the owner's launchpad label and the owner's unattached label to a mosaic-stack task (201). Another user's label gave 403.
2. This is intended upstream behavior. pkg/models/label_test.go (#3592) says a bot reads labels its owner created and labels sibling bots created.
3. Control: the same bot, owned by a separate account svc-mosaic-stack that owns no labels, was shared into the same project with the same scopes.
   • GET /labels showed only owner-label-on-ms-task, the one label attached to a task in mosaic-stack.
   • Attaching the owner's launchpad label gave 403, and so did the owner's unattached label. The label already on an ms task gave 201.
   • After the owner detached that label from every ms task, the bot saw [].
   • After another member attached their own label to an ms task, the bot saw that label.
   • The owner's account can't mint a token for svc's bot: POST /tokens gave 404/1005. Token minting has to run as the svc account.
4. A regular shared member sees their own labels plus the labels on tasks they can read. Bots are the only case that leaks.

What I recommend for T236 and the runbook:

• Create the five bot-$BIZ-* accounts from a dedicated per-business owner account. It owns no labels and no other bots, and it isn't Jason's account. Share the bots into the project as the runbook already does.
• Mint the tokens while logged in as that account.
• In S3, the broker also accepts only label ids listed in the business file, so a label that becomes visible later can't be attached.

R. Revoking a bot's token (decision 68)

probe-s7f.mjs. svc-mosaic-stack creates bot bot-ms-pm and mints two tokens for it, a and b. The owner shares the bot into the project. Every account call uses a /login JWT, the same kind vklogin writes.

Request	Result
owner DELETE /tokens/{a}	403 Forbidden, token a still 200
bot DELETE /tokens/{a} with token a	401/11, token a still 200
svc DELETE /tokens/{a}	204
token a straight after, and 1.5 s later	401/11
token b after a's revoke	200
svc DELETE /tokens/{a} again	403 Forbidden
svc GET /tokens	[], the bot's tokens aren't listed
svc GET /tokens?owner_id={bot}	items envelope with a and b, then only b
owner GET /tokens?owner_id={bot}	404/1005
svc mints token c, then calls with c and a	c 200, a 401/11

• Only the account that owns the bot can revoke its tokens, and the revoke takes effect on the next request. Revoking one token leaves the bot's other tokens working.
• To find an old token's id, list with owner_id as svc. A plain GET /tokens returns only svc's own tokens.

O. Startup probe order

The order in addendum B section 3 holds. With the minimal scopes, every probe against a missing task gives 401/11 before any 404:

• sync PATCH /tasks/{missing} {}, pm DELETE, coder DELETE and coder POST /tasks/{missing}/labels.
• The controls (GET /tasks/{missing} 404/4002, sync GET /projects/{p} 200) show that the token itself works.
• An over-broad token gets 404/4002 on the same probes. That 404 is the signal that the token has more scope than it needs.
• An over-broad sync token's PATCH {} on an existing task returns 304 and writes nothing.
• An unknown token and an expired token both give 401/11.
• A mint with a past expires_at is accepted (201), so S3 checks expiry itself.

U. What bumps updated

Change	Bumps updated	How
PATCH of an owned field	yes	in the request
PATCH with the same value	no, 304
label add or remove	yes	in the request
comment create, edit or delete	yes	async listener
assignee add or remove	yes	async listener
relation create or delete	yes, source task only	async listener
move between open buckets	no
move into done	yes, sets done

• The comment row is a correction to my first run, which recorded "comment create does not bump". The listener is HandleTaskUpdateLastUpdated, which pkg/models/listeners.go registers for comment, assignee, attachment and relation events and dispatches on commit.
• Measured lag (probe-s7e.txt): three comments on an idle server, two by the bot token and one by the owner. Each bump showed on the read 0 ms after the 201, and reads at 50 ms to 4 s showed the same value.
• In the first run (probe-s7.txt), with other writes in flight, the read straight after the comment showed no bump. The next read, 5 s later, showed it. That bounds the lag under load at 5 s. It isn't a measurement of the lag itself. The 60 s poll window is twelve times that bound.
• updated is reported to the second. Comment and label created carry nanoseconds in the POST answer only. Read back with GET, they're whole seconds too, and the comment check's bound is floored to match.

Paging and the poll cursor

• max_items_per_page is 50, and per_page=200 is capped at 50 on the board and the list.
• Board paging works past 50. With 121 tasks in one bucket, pages held 50, 50 and 21, every page reported count 121, and all 121 ids were distinct.
• The list envelope is {items, total, page, per_page, total_pages}.
• Sorting by updated,id ascending orders correctly.
• 120 creates took 565 ms, so many tasks share one reported second.
• On this sqlite instance, a date filter can't select one reported second:
  • updated = T returned 0, even with 13 tasks showing updated T.
  • Those 13 matched updated < T, and tasks reported at T+1 s matched updated < T+1s. The stored value and the reported second disagree by up to a second.
  • Windows with a margin work: updated > T-1s && updated < T+1s returned all 60.
  • A window plus id > X, sorted by id, pages correctly.
  • The .000Z, +00:00 and quoted forms parse. A space-separated form gives 400.

What S3 does with this:

• The poll lower bound is the previous poll's start time minus a margin, not the largest updated seen. The margin is 60 s, which covers listener lag and rounding.
• Pages are walked with id > last under a fixed window.
• Snapshots dedupe overlap: a task whose fields match task_current produces no new row.
• Moves between open buckets don't bump updated, so the board read stays in every cycle. The reconcile's comment_count covers comments.

D. Removing what isn't there

Request	Result
unassign a user who isn't assigned	204 (silent)
remove a label that isn't on the task	403
remove a relation that doesn't exist	404/4009
assign a user who is already assigned	400/4021
add a label that is already on the task	400/8001

Because unassign is silent, S3 compares before every unassign and records an absent target as a no-op, not as a success.

Writes and moves

• PATCH bucket_id alone returns 200 and echoes the new bucket_id, but the board bucket doesn't change. S3 refuses bucket_id in PATCH (decision 51), and the fake rejects it too.
• PATCH with an unknown key gives 422.
• PUT …/buckets/{b}/tasks {task_id} into the done bucket sets done:true.
• On sqlite, a write right after an assignee change got 500 database is locked: the listener held the write lock. S3 treats any 5xx or network error on a write as an uncertain outcome. It re-reads and compares, and it never retries under the same approval (bus README rule).

M. Tasks that leave the project

Case	sync bot GET /tasks/{t}	Snapshot
moved to a project shared with the sync bot	200, new project_id	moved with project
moved to a project not shared with it	403, no code	no-access
deleted	404/4002	not-found

Other

• GET /tasks/{t} returns an ETag, and If-None-Match gives 304.
• Rate limit: tested with it enabled at 8 per 60 s and the default kind: user.
  • Bot A got 200 eight times (x-ratelimit-remaining 7 down to 0), then 429.
  • Bot B, from the same IP straight after, got 200 with 7 remaining.
  • The limit is per account, so one busy role can't starve the others.
  • The source agrees: pkg/routes/rate_limit.go keys by user_<id> and falls back to the IP for unauthenticated requests.
• Install: a new kanban view starts with manual buckets. Renaming the three defaults with PUT and adding in-review and blocked with POST keeps done_bucket_id and default_bucket_id pointing at the right buckets.

G. Reads S3 relies on (probe-s7g)

Same scratch container and digest, four tasks in one project. These were assumptions in the code until this run; each one held.

• related_tasks is an object keyed by kind. Each value is an array of full task objects. After t2 blocked t1, t2 shows {"blocked":[t1]} and Vikunja adds {"blocking":[t2]} to t1 on its own. The task read, the project list and the board all carry it.
• After an assign, the task read and the board both return assignees as an array of user objects. With no assignee the field is null, not [].
• A user object for a person leaves out bot_owner_id. A bot's has it.
• The project list with no done filter returns done tasks. So does the cursor filter updated > … && id > 0. A close made in the UI is therefore seen by the cursor, not only by the board diff.
• PATCH due_date: null returns 200 and stores 0001-01-01T00:00:00Z. S3 reads that value as no due date.
• GET /tasks/2147483647 and /tasks/2147483648 both give 404/4002. The startup probe uses the first as its missing id.
• The id-keyed walk (id > last, sort_by id, per_page 2) over four tasks returned [1,2,3,4] in three pages, the last one empty.

The three reads with a relation are in tests/fixtures/v2-shapes.json as the related entries, and the shapes test compares the fake against them.