-
Notifications
You must be signed in to change notification settings - Fork 492
Unified agent logging and fixes queue processor #171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
michaelerobertsjr
wants to merge
6
commits into
TinyAGI:main
Choose a base branch
from
michaelerobertsjr:t3code/pino-unified-agent-logging
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 2 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
d0274ba
Unify TinyClaw runtime logging with structured pino logs
9af11f4
Unify runtime logging and harden queue/channel shutdown flow
f9fbdcb
Track conversation IDs in queued responses and tighten logging
fdd4398
Unify heartbeat logging with shared structured logger
a8c60a1
Harden logging paths and return 500 on agent provision errors
00e0639
Harden log search matching and normalize level filters
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,116 @@ | ||
| # Response Delivery Options for `heartbeat`, `web`, and `cli` | ||
|
|
||
| ## Problem | ||
|
|
||
| TinyClaw currently writes outgoing responses for all channels into the `responses` table, but only the Telegram, Discord, and WhatsApp channel clients poll `/api/responses/pending` and call `/api/responses/:id/ack`. | ||
|
|
||
| That leaves these channels with no delivery consumer: | ||
|
|
||
| - `heartbeat` | ||
| - `web` | ||
| - `cli` | ||
|
|
||
| As a result, their rows remain `status = 'pending'` indefinitely even when the response was already useful for logging or operator visibility. | ||
|
|
||
| ## Current State | ||
|
|
||
| - `heartbeat` responses are generated by the queue processor and only observed indirectly by `lib/heartbeat-cron.sh` via `GET /api/responses?limit=20`. | ||
| - `web` responses are visible in logs and TinyOffice data, but there is no response delivery worker or ack path for them. | ||
| - `cli` responses can be inspected through the API and DB, but there is no terminal-side consumer that acks them. | ||
|
|
||
| ## Option 1: Auto-ack non-delivery channels after enqueue | ||
|
|
||
| ### Design | ||
|
|
||
| Treat `heartbeat`, `web`, and `cli` as non-delivery channels. Continue writing their responses to the `responses` table for audit/history, but immediately mark them `acked` after enqueue. | ||
|
|
||
| ### Pros | ||
|
|
||
| - Smallest code change | ||
| - `responsesPending` becomes a real signal for only deliverable channels | ||
| - No long-term buildup from pseudo-channels | ||
| - Keeps historical response rows | ||
|
|
||
| ### Cons | ||
|
|
||
| - You lose visibility into "not yet viewed" versus "already viewed" | ||
| - `acked` stops meaning "delivered to an external user" and becomes "no further delivery required" | ||
|
|
||
| ### Best fit | ||
|
|
||
| Use this if `heartbeat`, `web`, and `cli` are primarily observability/operator channels, not real outbound transport queues. | ||
|
|
||
| ## Option 2: Add explicit consumers and ack on read | ||
|
|
||
| ### Design | ||
|
|
||
| Keep all responses pending until a channel-specific consumer reads them: | ||
|
|
||
| - TinyOffice web UI fetches pending `web` responses and acks after display | ||
| - CLI tooling fetches pending `cli` responses and acks after printing | ||
| - heartbeat runner fetches pending `heartbeat` responses and acks after logging | ||
|
|
||
| ### Pros | ||
|
|
||
| - Preserves strict queue semantics | ||
| - `pending` accurately means "not yet consumed" | ||
| - Best model if those channels should behave like real delivery targets | ||
|
|
||
| ### Cons | ||
|
|
||
| - Most code and coordination work | ||
| - Web/CLI delivery semantics need to be defined precisely | ||
| - UI refreshes and polling create ambiguity around what counts as "consumed" | ||
|
|
||
| ### Best fit | ||
|
|
||
| Use this if you want `web`, `cli`, and `heartbeat` to behave as first-class delivery channels with lifecycle guarantees. | ||
|
|
||
| ## Option 3: Split delivery queues from audit records | ||
|
|
||
| ### Design | ||
|
|
||
| Only enqueue into `responses` for channels that have delivery workers. For `heartbeat`, `web`, and `cli`, store final outputs somewhere else: | ||
|
|
||
| - structured logs | ||
| - chat history files | ||
| - a new `response_history` table | ||
|
|
||
| ### Pros | ||
|
|
||
| - Cleanest semantics long term | ||
| - `responses` remains a true delivery queue | ||
| - Avoids overloading `acked` | ||
|
|
||
| ### Cons | ||
|
|
||
| - Larger schema and API change | ||
| - Requires migration of any UI that currently expects all outputs in `responses` | ||
| - More implementation effort than Option 1 | ||
|
|
||
| ### Best fit | ||
|
|
||
| Use this if you want a clean architectural separation between "deliver this" and "record that it happened." | ||
|
|
||
| ## Recommendation | ||
|
|
||
| Recommend **Option 1** first. | ||
|
|
||
| It solves the operational problem quickly: | ||
|
|
||
| - `responsesPending` becomes meaningful again | ||
| - backlog metrics stop being polluted by non-delivery channels | ||
| - response history is still preserved in SQLite | ||
|
|
||
| If later you want inbox-like behavior for `web` or `cli`, you can move to Option 2 or Option 3 with clearer semantics. | ||
|
|
||
| ## Suggested Decision | ||
|
|
||
| Short term: | ||
|
|
||
| - implement Option 1 for `heartbeat`, `web`, and `cli` | ||
|
|
||
| Medium term: | ||
|
|
||
| - decide whether `web` should graduate to a true consumer flow | ||
| - if yes, move `web` to Option 2 while leaving `heartbeat` on Option 1 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.