Deploy taosmd to the Pi: 15 commits behind, carries the WAL/busy-timeout fix for SQLITE_BUSY under concurrent agents

[jaylfc]

CARD TITLE (intent, not commit subject): Deploy taosmd to the Pi: 15 commits behind, carries the WAL/busy-timeout fix for SQLITE_BUSY under concurrent agents

Autonomous build of board card tsk-no436s.

REVIEW WARNING (automated): this card's text asks for tests, but the diff changes no test file. Either the acceptance criteria are unmet or the card needs correcting. Do not merge without resolving this.

registry: per-identity token rotation via token_min_iat (fixes #2205)

Files:
changelog.d/2290-changelog-fragments.md | 6 ++++++
changelog.d/2298-tasks-to-routines.md | 5 +++++
changelog.d/2313-consent-defer-active-handle.md | 7 +++++++
changelog.d/2314-cryptography-50.md | 5 +++++
desktop/package.json | 2 +-
pyproject.toml | 2 +-
tinyagentos/init.py | 2 +-
9 files changed, 29 insertions(+), 30 deletions(-)

[coderabbitai]

Warning

Review limit reached

@jaylfc, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 25 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 3420ad36-1a45-4090-b072-2b4983870d84

📥 Commits

Reviewing files that changed from the base of the PR and between fc1de1d and 3ba6833.

⛔ Files ignored due to path filters (1)

• uv.lock is excluded by !**/*.lock, !**/uv.lock

📒 Files selected for processing (5)

• tests/test_agent_registry_store.py
• tests/test_token_rotation.py
• tinyagentos/agent_registry_store.py
• tinyagentos/agent_token_auth.py
• tinyagentos/routes/agent_registry.py

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[gitar-bot]

Important

You are using the Gitar free plan. Upgrade to unlock code review, CI analysis, auto-apply, custom automations, and more.

_Gitar

[jaylfc]

Closing as a stale replay: this diff is PR #2208's token-rotation content (same five files, same commit subject, fixes #2205), which merged to dev at 14:4xZ today — replaying it would be a no-op at best and a regression risk against the moved base. Separately, card tsk-no436s is an operational deploy task (taosmd → Pi, which bounces the A2A bus on :7900 and needs an announced window), not a repo change — it is lead-only and should never have been offered to a lane. Same dispatch-class defect as tsk-5ypylc tracks; instance recorded there.

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[kilo-code-bot]

WARNING: TOCTOU race condition in bump_token_min_iat — MAX(token_min_iat, ?) is not atomic with respect to the read-modify-write cycle

If two concurrent requests arrive with different timestamps, both read the current value first, then whichever UPDATE executes last wins. If Request A (ts=3000) writes first and Request B (ts=2000) writes second, the final value becomes 2000 — moving the cutoff backward and re-validating tokens that should remain superseded.

Example interleaving:

1. Request A reads token_min_iat=0
2. Request B reads token_min_iat=0
3. Request A executes: MAX(0, 3000) → 3000
4. Request B executes: MAX(0, 2000) → 2000 ← regression

Fix: add a guard to the WHERE clause so the update is a no-op when the stored value is already >= the proposed timestamp:

UPDATE agent_registry SET token_min_iat = ? WHERE canonical_id = ? AND token_min_iat < ?

This guarantees monotonic forward progress regardless of write order.

---

Reply with @kilocode-bot fix it to have Kilo Code address this issue.

[kilo-code-bot]

Code Review Summary

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity	Count
WARNING	1

Issue Details (click to expand)

WARNING

File	Line	Issue
tinyagentos/agent_registry_store.py	887	TOCTOU race in bump_token_min_iat: MAX(token_min_iat, ?) allows the cutoff to move backward if a later concurrent request has a smaller timestamp. Add AND token_min_iat < ? to the WHERE clause to enforce monotonic forward progress.

Files Reviewed (5 files)

• tinyagentos/agent_registry_store.py - 1 issue
• tinyagentos/agent_token_auth.py
• tinyagentos/routes/agent_registry.py
• tests/test_agent_registry_store.py
• tests/test_token_rotation.py

Fix these issues in Kilo Cloud

---

_{Reviewed by step-3.7-flash · Input: 149.6K · Output: 11.7K · Cached: 758.7K}