## Issue Triage — 2026-05-05 (elizaOS)

### 1) Agents incorrectly report lack of task + memory tools (TBD Issue ID — needs filing)
- **Current Status:** Newly observed in dev logs (not linked to a GitHub issue in provided data); reproducibility unknown; likely affecting multiple agents.
- **Impact Assessment:**
  - **User Impact:** **High** (breaks expected agent capabilities broadly)
  - **Functional Impact:** **Yes** (core agent “tools” availability impacts tasks, memory, evaluators/providers)
  - **Brand Impact:** **High** (agents appearing “incapable” undermines trust in framework)
- **Technical Classification:**
  - **Category:** Bug
  - **Component:** Core Framework (agent runtime tooling, providers/evaluators)
  - **Complexity:** Moderate effort (may involve tool registry, capability detection, or config application)
- **Resource Requirements:**
  - **Required Expertise:** Agent runtime internals; tool registration; memory/task pipeline
  - **Dependencies:** None, but needs quick repro + logs
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. File a GitHub issue with exact agent(s), runtime mode (desktop/self-host/cloud), and logs showing missing tools.
  2. Add a startup “capability dump” log (task tools, memory tools, providers enabled) to make regressions obvious.
  3. Identify whether this correlates with recent config env application changes (e.g., vault sentinel skipping) or plugin lifecycle decoupling.
  4. Create a minimal integration test: fresh DB + default character + verify task/memory tools present after boot.
- **Potential Assignees:** **stan0473**, **lalalune**, **Dexploarer** (runtime/tooling), with support from **2-A-M** (integration tests)

---

### 2) Telegram wrapper bypasses agent runtime, preventing skill/action dispatch (TBD Issue ID — needs filing)
- **Current Status:** Newly identified in dev logs; suggests messages are handled outside the standard runtime pipeline.
- **Impact Assessment:**
  - **User Impact:** **High** (Telegram is a major connector; skills/actions not firing breaks key value prop)
  - **Functional Impact:** **Yes** (connector messages not routed through runtime → no actions/skills/tools)
  - **Brand Impact:** **High** (“works sometimes / not at all” is a common user-facing failure mode)
- **Technical Classification:**
  - **Category:** Bug / Integration
  - **Component:** Plugin System (Telegram) + App runtime wrappers
  - **Complexity:** Complex solution (requires deciding single source of truth for Telegram ingestion)
- **Resource Requirements:**
  - **Required Expertise:** Connector architecture, runtime message bus, Telegraf lifecycle
  - **Dependencies:** Related historical failures: dual polling + bun/Windows launch issues (recently closed items indicate churn)
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. File an issue capturing the current architecture: where wrapper intercepts vs plugin-telegram event path.
  2. Enforce **one** Telegram ingestion path:
     - Either wrapper routes into runtime via the same event pipeline as plugin-telegram, **or**
     - wrapper is removed and plugin-telegram is fixed to be reliable cross-platform.
  3. Add an automated e2e test: send N messages → expect N memories + N replies + at least one action dispatch when prompted.
  4. Add runtime warning if two Telegram consumers are active (detect multiple pollers / multiple Telegraf instances).
- **Potential Assignees:** **stan0473** (core), **vyctorbrzezowski** (Telegram plugin familiarity), **lalalune** (app-core/runtime integration)

---

### 3) `dangerously-skip-permissions` flag does not bypass confirmation loops (TBD Issue ID — needs filing)
- **Current Status:** Newly identified in dev logs; flag exists but behavior doesn’t match expected override.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (blocks automation/CI flows and power users)
  - **Functional Impact:** **Partial** (core still runs, but permission-gated actions become unusable)
  - **Brand Impact:** **Medium** (makes system feel unpredictable and “stuck”)
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component:** Core Framework (permissions/confirmations), possibly CLI/app-core settings
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Permissions policy engine, action dispatch, confirmation UX
  - **Dependencies:** None
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Define expected semantics: skip *which* confirmations (tool execution, financial actions, external writes)?
  2. Add a unit test: with flag enabled, action executes without a confirmation request.
  3. Trace confirmation loop: identify whether confirmations are emitted by evaluators vs action middleware.
  4. Add explicit logging: “confirmation bypassed due to dangerously-skip-permissions”.
- **Potential Assignees:** **Dexploarer** (runtime ops/policy), **2-A-M** (tests/UI), **lalalune** (core integration)

---

### 4) Activity panel flickers under high-volume WebSocket events (TBD Issue ID — needs filing)
- **Current Status:** Newly identified in dev logs; likely a regression from high-frequency state updates.
- **Impact Assessment:**
  - **User Impact:** **Medium** (annoying; reduces usability for power users)
  - **Functional Impact:** **Partial** (doesn’t stop agents, but harms monitoring/workflow)
  - **Brand Impact:** **Medium** (UI perceived as unstable)
- **Technical Classification:**
  - **Category:** Performance / UX
  - **Component:** GUI (app-core activity/monitoring panel), WebSocket event handling
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** React performance patterns, state batching, websocket event throttling
  - **Dependencies:** None
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Capture a performance profile with simulated event storm (dev tool + log rate).
  2. Add debouncing/batching at the websocket reducer level (aggregate updates per frame / per 100ms).
  3. Ensure stable keys and avoid remount loops in list rendering.
  4. Add a stress test / storybook scenario for activity feed at high QPS.
- **Potential Assignees:** **2-A-M** (UI), **lalalune** (app-core), **NubsCarson** (perf)

---

### 5) Cloud app-scoped chat endpoint returns 500 for auth failures (TBD Issue ID — should be filed from PR #7376 review)
- **Issue Title & ID:** `cloud: /api/v1/apps/:appId/chat misclassifies AuthenticationError/ForbiddenError as 500` (TBD)
- **Current Status:** **In merged code path** (PR **#7376**). Greptile flagged as P1 risk; requires verification in staging/prod.
- **Impact Assessment:**
  - **User Impact:** **High** (breaks API clients; prevents correct retry/handling; confusing failures)
  - **Functional Impact:** **Yes** (monetized app chat is a core Cloud monetization path)
  - **Brand Impact:** **High** (500s for auth look like platform instability)
- **Technical Classification:**
  - **Category:** Bug
  - **Component:** Cloud API (auth middleware + route error handling)
  - **Complexity:** Simple fix (error mapping + Promise.all structure)
- **Resource Requirements:**
  - **Required Expertise:** Cloud API routing (Hono/Workers), auth error taxonomy
  - **Dependencies:** None
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Add a failing unit/integration test: invalid API key → expect 401/403 (not 500).
  2. Refactor to validate auth outside `Promise.all` or explicitly catch and rethrow as typed HTTP responses.
  3. Audit other routes for similar Promise.all error swallowing.
- **Potential Assignees:** **standujar** (cloud auth), **0xSolace** (cloud stabilization), **NubsCarson** (PR author context)

---

### 6) Cloud domain sync never sets Cloudflare-managed domains to `verified=true` (TBD Issue ID — should be filed from PR #7376 review)
- **Current Status:** **In merged code path** (PR **#7376**). Impacts CORS origin verification and domain activation completeness.
- **Impact Assessment:**
  - **User Impact:** **High** (custom domains appear “broken”; CORS remains blocked)
  - **Functional Impact:** **Yes** (domain hosting + monetized apps require verified origins)
  - **Brand Impact:** **High** (domains are a premium feature; broken verification is reputationally costly)
- **Technical Classification:**
  - **Category:** Bug
  - **Component:** Cloud API (managed domains / sync / CORS origins)
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Cloud domain lifecycle, CORS origin lists, Cloudflare provisioning status
  - **Dependencies:** None
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Add test: purchase pending → later sync status active → expect verified=true and origin included.
  2. Patch sync route to set verified when zone provisioning completes.
  3. Backfill existing domains in DB: one-time migration or admin script to re-sync + mark verified.
- **Potential Assignees:** **NubsCarson**, **standujar**, **0xSolace**

---

### 7) Cloud monetized chat credit reconciliation/refund edge cases (TBD Issue ID — should be filed from PR #7376 review)
- **Current Status:** **In merged code path** (PR **#7376**). Multiple failure modes: free inference on reconciliation failure (streaming) and user charged/no response/no refund (non-streaming).
- **Impact Assessment:**
  - **User Impact:** **Critical** (billing correctness; either revenue loss or user harm)
  - **Functional Impact:** **Yes** (monetization/billing correctness is core platform function)
  - **Brand Impact:** **Critical** (billing bugs are trust-destroying)
- **Technical Classification:**
  - **Category:** Bug / Reliability
  - **Component:** Cloud API (billing/credits reconciliation, streaming response lifecycle)
  - **Complexity:** Complex solution (transactionality with partial streaming completion)
- **Resource Requirements:**
  - **Required Expertise:** Billing systems, idempotency, streaming semantics, failure handling
  - **Dependencies:** Might require changes in billing service + route contract
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Define correctness rules:
     - If content delivered, never refund to zero solely due to reconciliation failure.
     - If provider succeeded but reconcile fails, return content and queue reconciliation retry (or escrow model).
  2. Add idempotency keys per chat run and reconcile asynchronously with retry + dead-letter.
  3. Add integration tests covering:
     - Streaming success + reconcile throws
     - Non-streaming success + reconcile throws
     - DB write fails after registrar purchase (ensure refund)
  4. Add metrics/alerts: mismatch between delivered tokens and billed tokens; refund spikes.
- **Potential Assignees:** **standujar** (cloud reliability), **NubsCarson** (feature context), **0xSolace** (stabilization)

---

### 8) Cloud container control-plane internal auth is a no-op if token env missing (TBD Issue ID — should be filed from PR #7376 review)
- **Current Status:** **In merged code path** (PR **#7376**). Security posture depends on env correctness.
- **Impact Assessment:**
  - **User Impact:** **Medium** (primarily platform-side risk; could become user impact if exploited)
  - **Functional Impact:** **Partial** (service works but with unsafe defaults)
  - **Brand Impact:** **High** (security misconfig defaults are risky)
- **Technical Classification:**
  - **Category:** Security
  - **Component:** Cloud infra (container control-plane)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Cloud security, service-to-service auth, deployment configs
  - **Dependencies:** Needs coordinated deploy updates (ensure token always set)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Change default behavior: if token env missing, **fail closed** (reject all requests).
  2. Add deployment validation: CI check that required env vars exist for production/staging.
  3. Add security test: request without token returns 401/403.
- **Potential Assignees:** **0xSolace**, **standujar**, **NubsCarson**

---

### 9) Slack connector: unguarded `getUser()` can throw and silently drop inbound messages (TBD Issue ID — post-merge regression risk from PR #7375 review)
- **Current Status:** Slack plugin migrated and merged (PR **#7375**). Greptile flagged missing try/catch in core event handlers.
- **Impact Assessment:**
  - **User Impact:** **High** (Slack is a primary enterprise connector; message loss is severe)
  - **Functional Impact:** **Yes** (dropped inbound messages break core chat loop)
  - **Brand Impact:** **High** (connector reliability is highly visible)
- **Technical Classification:**
  - **Category:** Bug / Reliability
  - **Component:** Plugin System (Slack connector)
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Slack Bolt/SDK error handling, message ingestion pipeline
  - **Dependencies:** None
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Wrap `users.info` in try/catch; on failure, continue with minimal user identity (fallback id) and log warning.
  2. Add retry/backoff for rate limits; ensure event handler doesn’t throw.
  3. Add a test that simulates Slack API failure and asserts message still becomes a memory and triggers agent reply.
- **Potential Assignees:** **2-A-M** (connector integration), **odilitime** (plugin/ops), **stan0473** (core review)

---

### 10) Discord server spam filter blocks legitimate URLs (Ops issue — no GitHub ID provided)
- **Current Status:** Reported in Discord; workaround is wrapping URLs in backticks. Indicates moderation tooling too strict.
- **Impact Assessment:**
  - **User Impact:** **Medium** (friction in support + developer collaboration)
  - **Functional Impact:** **No** (does not block runtime, but blocks community workflows)
  - **Brand Impact:** **Medium** (community support quality)
- **Technical Classification:**
  - **Category:** UX / Community Ops
  - **Component:** Discord moderation configuration/bot
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Discord moderation bots/AutoMod, anti-spam tuning
  - **Dependencies:** Needs ongoing anti-bot posture
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Whitelist common domains (github.com, docs links, elizaos domains) and allow URLs for trusted roles.
  2. Replace “blanket block” with rate limits + reputation/role gates.
  3. Document the workaround in a pinned message until tuned.
- **Potential Assignees:** **odilitime** (community ops), **satsbased** (mod), **shawmakesmagic** (server policy)

---

## Summary: Top 5–10 Highest Priority Issues (Immediate Attention)

1. **P0:** Agents report missing task/memory tools (core runtime capability regression) — *TBD ID*
2. **P0:** Telegram wrapper bypasses runtime → no skills/actions dispatch (connector correctness) — *TBD ID*
3. **P0:** Cloud monetized chat billing reconciliation/refund correctness (revenue loss + user harm) — *TBD ID*
4. **P0:** Cloud app-scoped chat auth failures misreported as 500 (breaks clients; looks like outage) — *TBD ID*
5. **P0:** Cloud domain sync never marks domains verified (breaks CORS + custom domains) — *TBD ID*
6. **P0:** Container control-plane internal auth no-op when env missing (fail-open security risk) — *TBD ID*
7. **P1:** Slack inbound message drops when Slack API user lookup fails (connector reliability) — *TBD ID*
8. **P1:** `dangerously-skip-permissions` doesn’t actually bypass confirmation loops (automation blocked) — *TBD ID*
9. **P2:** Activity panel flicker under high WebSocket load (UI stability/perf) — *TBD ID*
10. **P2:** Discord URL spam filter too aggressive (community workflow friction) — *Ops*

---

## Patterns / Themes Suggesting Deeper Architectural Problems

1. **Multiple ingestion paths bypassing the runtime contract (connectors):** Telegram issues point to duplicated or parallel message pipelines (wrapper vs plugin). This is a recurring risk whenever platform-specific workarounds are introduced outside the plugin lifecycle.
2. **Error handling quality gaps at boundaries (connectors + Cloud routes):** Several critical problems are “silent drop” or “wrong status code,” indicating insufficient typed error mapping and lack of contract tests for failure modes.
3. **Monetization/billing correctness not isolated from delivery path:** Cloud streaming/non-streaming reconciliation being tightly coupled to response lifecycle creates opportunities for “delivered but not billed” or “billed but not delivered.”
4. **Security posture depends on configuration presence rather than safe defaults:** The control-plane token behavior indicates fail-open patterns that should be eliminated.

---

## Recommendations: Process Improvements

1. **Introduce “boundary contract tests” for each connector and monetized chat route**
   - For connectors: “N inbound messages → N memories + N replies,” including simulated upstream API failures.
   - For Cloud monetized chat: tests for auth error codes, streaming reconciliation failures, and idempotent billing.
2. **Enforce single source of truth for connector ingestion**
   - Add runtime detection + warnings/errors when two consumers are active for the same connector/token.
   - Require that any wrapper/workaround still dispatches through the same runtime event bus.
3. **Adopt fail-closed defaults for internal auth**
   - If required env is missing, refuse to start or reject requests; add CI checks to prevent deploying with missing secrets.
4. **Pre-merge “risk checklist” for monetization changes**
   - Explicit review gates: refund logic, idempotency keys, partial streaming completion semantics, and audit logging/metrics.
5. **Improve issue hygiene from dev logs**
   - Any “identified issue” in daily summaries should immediately map to a GitHub issue with: repro steps, affected version/commit, and owner. This prevents P0s from living as untracked notes.