## Issue Triage — 2026-01-08

### 1) Discord bot fails in elizaOS v1.7.0: “No server ID found 10” (serverId → messageServerId migration fallout) — PR #6333 / branch `odi-17`
- **Current Status:** PR #6333 merged (core). Field migration still causing real-world breakage with plugin-discord v1.3.3; users advised to downgrade to core v1.6.5 or test `odi-17`.
- **Impact Assessment:**
  - **User Impact:** **High** (anyone upgrading to core 1.7.0 with Discord)
  - **Functional Impact:** **Yes** (Discord integration effectively broken)
  - **Brand Impact:** **High** (bots “don’t work” after upgrade)
- **Technical Classification:**
  - **Category:** Bug / Compatibility
  - **Component:** Core Framework + Plugin System (plugin-bootstrap, plugin-discord integration surface, plugin-sql schema naming)
  - **Complexity:** **Moderate effort** (edge cases + cross-version compatibility)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript, event/message schema evolution, Discord plugin runtime flows, regression testing
  - **Dependencies:** plugin-discord release pipeline health (see issue #40), multi-branch Discord testing matrix
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Reproduce on a minimal Discord bot + core v1.7.0 + plugin-discord v1.3.3 with verbose logging of room/world fields (`serverId`, `messageServerId`).
  2. Add a short-term compatibility shim: accept both fields in critical code paths (read old, write new) where safe.
  3. Cut a patched core release (e.g., 1.7.1) with release notes explicitly calling out migration behavior.
  4. Add an automated regression test that asserts Discord room context always has a stable server identifier.
- **Potential Assignees:** **odilitime** (root-cause + patch author), **standujar (Stan ⚡)** (messaging API alignment/testing), **shaw** (Discord architecture oversight)

---

### 2) plugin-discord publishing pipeline failure blocks v1.3.4 — elizaos-plugins/plugin-discord Issue #40
- **Current Status:** Open / under investigation; blocking new plugin-discord release.
- **Impact Assessment:**
  - **User Impact:** **High** (prevents shipping fixes to a widely used connector)
  - **Functional Impact:** **Partial** (existing installs work, but fixes can’t be delivered)
  - **Brand Impact:** **High** (looks like the project can’t ship)
- **Technical Classification:**
  - **Category:** Bug / Release Engineering
  - **Component:** Plugin System / CI-CD
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** npm publishing, GitHub Actions, semver/release tooling, provenance/signing (if used)
  - **Dependencies:** Needed to ship Discord compatibility fixes and unified messaging API changes
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Identify failing step (auth, provenance, build artifact, tag/version mismatch) and capture logs in the issue.
  2. Verify package.json versioning + tags + changelog generation; ensure CI uses correct NPM_TOKEN scopes.
  3. Run a dry-run publish from CI environment or reproduce in a minimal workflow.
  4. Once fixed, publish v1.3.4 immediately and backfill a “release checklist” doc.
- **Potential Assignees:** **standujar (Stan ⚡)**, **shaw**, (support) **odilitime**

---

### 3) Telegram plugin crash when processing images uploaded as photos — elizaos-plugins/plugin-telegram Issue #23
- **Current Status:** Open; reported TypeError crash on certain image payloads.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (Telegram is a primary connector for many bots)
  - **Functional Impact:** **Yes** (hard crash)
  - **Brand Impact:** **High** (connector instability)
- **Technical Classification:**
  - **Category:** Bug
  - **Component:** Plugin System (plugin-telegram)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Telegram Bot API message formats (photo vs document), TypeScript runtime guards, media pipeline
  - **Dependencies:** None, but should align with unified messaging API changes if they touch ingestion
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add fixtures for Telegram “photo” updates (multiple sizes) and any missing fields that trigger the TypeError.
  2. Implement strict null/shape guards + fallback extraction of file_id.
  3. Add integration test that processes photo payloads end-to-end without crashing.
  4. Ship a patch release for plugin-telegram once validated.
- **Potential Assignees:** **standujar (Stan ⚡)**, **wtfsayo** (robust adapter-style fixes), (support) **cjft**

---

### 4) Cloud: TOCTOU race condition in credit deduction for streaming endpoints (deduct-before, reconcile-after) — (tracked via Linear tickets; no GitHub ID provided)
- **Current Status:** In progress per standup; implementation underway.
- **Impact Assessment:**
  - **User Impact:** **High** (billing/credits correctness affects many cloud users)
  - **Functional Impact:** **Partial** (requests work, but accounting can be wrong)
  - **Brand Impact:** **High** (trust + billing correctness)
- **Technical Classification:**
  - **Category:** Bug / Reliability
  - **Component:** Cloud Runtime / API (streaming endpoints)
  - **Complexity:** **Complex solution** (concurrency, idempotency, reconciliation)
- **Resource Requirements:**
  - **Required Expertise:** distributed systems, transactional patterns, idempotency keys, streaming lifecycle
  - **Dependencies:** telemetry/metrics to validate reconciliation accuracy; possibly DB constraints/UPSERT patterns
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Define invariants (never negative credits; reconciliation must converge; duplicate stream events safe).
  2. Add an idempotency key per stream/session chunk for billing events.
  3. Implement deduct-before with atomic update + reconcile job; add stress tests (concurrent streams, retries).
  4. Add dashboards/alerts for “credit mismatch rate” and reconcile lag.
- **Potential Assignees:** **standujar (Stan ⚡)**, (support) **wtfsayo**

---

### 5) High memory consumption / suspected leaks or unbounded growth — elizaos/eliza Issue #6332
- **Current Status:** Open (performance challenge identified in weekly summary).
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (long-running agents, cloud workloads)
  - **Functional Impact:** **Partial** (degrades stability; can OOM)
  - **Brand Impact:** **High** (perceived “unstable/heavy”)
- **Technical Classification:**
  - **Category:** Performance / Reliability
  - **Component:** Core Framework + Runtime + possibly plugin-sql caching/DB layers
  - **Complexity:** **Complex solution**
- **Resource Requirements:**
  - **Required Expertise:** Node/Bun profiling, heap snapshots, async lifecycle management, caching strategy review
  - **Dependencies:** Repro harness; decision on caching approach (see draft caching PR #6329)
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Establish a reproducible scenario (soak test) and capture heap snapshots over time.
  2. Identify top retainers (message histories, embeddings, session caches, connectors).
  3. Add memory budgets + periodic cleanup where appropriate (TTL caches, bounded queues).
  4. Publish a short “profiling guide” so contributors can reproduce consistently.
- **Potential Assignees:** **wtfsayo**, **0xbbjoker** (DB/runtime optimization background), **standujar**

---

### 6) Parallel processing opportunities / message pipeline throughput — elizaos/eliza Issues #6334 and #6337
- **Current Status:** Open (performance roadmap items).
- **Impact Assessment:**
  - **User Impact:** **Medium** (high-traffic deployments, multi-agent workloads)
  - **Functional Impact:** **No** (not a blocker, but limits scale)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Category:** Performance
  - **Component:** Core message processing, provider execution, composeState/provider batching
  - **Complexity:** **Architectural change** (concurrency model and ordering guarantees)
- **Resource Requirements:**
  - **Required Expertise:** concurrency design, queueing/backpressure, deterministic state updates
  - **Dependencies:** Connector/event pump direction and worker architecture discussions (voice vs text priority)
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Decide what is safe to parallelize (providers? tool calls? embeddings?) with explicit ordering rules.
  2. Add benchmarks (latency p50/p95, throughput) before/after changes.
  3. Prototype behind a feature flag; validate correctness under retries and partial failures.
- **Potential Assignees:** **standujar (Stan ⚡)**, **odilitime**, (support) **0xbbjoker**

---

### 7) Unified messaging API alignment: plugin-discord should use `handleMessage` (not deprecated `sendMessage`) — elizaos-plugins/plugin-discord PR #41
- **Current Status:** PR submitted; needs review/merge and release (blocked by publishing issue #40).
- **Impact Assessment:**
  - **User Impact:** **Medium** (devs on newer unified API paths; reduces breakage)
  - **Functional Impact:** **Partial** (prevents drift and future breaks)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Category:** Bug-prevention / Tech debt
  - **Component:** Plugin System / Messaging API integration
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** messaging API, plugin-discord, backward compatibility
  - **Dependencies:** plugin-discord publishing pipeline (issue #40)
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2** (upgrade to P1 if it resolves real user breakage alongside the 1.7.0 Discord failures)
- **Specific Actionable Next Steps:**
  1. Review PR for behavior parity across DM/channel, mention/reply logic, and event dedupe.
  2. Add compatibility note in changelog (minimum core version, expected behavior).
  3. Merge and publish once pipeline is fixed.
- **Potential Assignees:** **standujar (Stan ⚡)**, **shaw**, (support) **odilitime**

---

### 8) “Model not found” when calling cloud agent APIs due to missing provider prefix — (Docs gap; no GitHub ID provided)
- **Current Status:** User confusion resolved via Discord guidance; needs official docs/API schema examples.
- **Impact Assessment:**
  - **User Impact:** **Medium** (common integration footgun)
  - **Functional Impact:** **Partial** (API calls fail until corrected)
  - **Brand Impact:** **Medium** (feels like “API is broken”)
- **Technical Classification:**
  - **Category:** Documentation / UX
  - **Component:** Cloud API / Docs
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** API docs, examples, possibly request validation improvements
  - **Dependencies:** None
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Update docs with explicit examples: `openai/gpt-4o-mini`, `anthropic/claude-sonnet-4.5`, `google/gemini-2.5-flash`.
  2. Add server-side validation error that suggests correct format when missing `/`.
  3. Add an SDK helper that constructs model IDs safely.
- **Potential Assignees:** **cjft** (provided solution), **jin** (docs workflow), **standujar**

---

### 9) Chat Box UI improvement: default to one line, expand dynamically — elizaos/eliza Issue #6310
- **Current Status:** Open (UX enhancement request; some UI work noted in weekly summary but issue remains as reference).
- **Impact Assessment:**
  - **User Impact:** **Low–Medium**
  - **Functional Impact:** **No**
  - **Brand Impact:** **Low–Medium** (polish)
- **Technical Classification:**
  - **Category:** UX
  - **Component:** GUI (client chat component)
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Frontend UI (React), textarea autosize behavior, layout testing
  - **Dependencies:** None
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Confirm current behavior vs desired (mobile + desktop).
  2. Implement autosize with max rows + smooth scroll anchoring.
  3. Add lightweight UI test to prevent regressions.
- **Potential Assignees:** **borisudovicic** (issue author), **standujar**

---

### 10) Agent memory documentation requested — elizaos/docs Issue #82
- **Current Status:** Open; requested due to community confusion/need.
- **Impact Assessment:**
  - **User Impact:** **Medium** (onboarding + correct usage)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (developer experience)
- **Technical Classification:**
  - **Category:** Documentation
  - **Component:** Docs (agent configuration, memory, embeddings, providers)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** elizaOS memory architecture, examples, best practices
  - **Dependencies:** Ensure docs match current unified hooks/messaging API terminology
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Document memory types, retention, embedding requirements, and common pitfalls (e.g., TEXT_EMBEDDING delegation).
  2. Provide 2–3 configuration recipes (local dev, cloud, connector-heavy bot).
  3. Add troubleshooting section (errors like missing embedding handler).
- **Potential Assignees:** **jin**, **cjft**, (support) **standujar**

---

## Top Priority Summary (address immediately)
1. **P0:** Discord breakage in core v1.7.0 due to serverId → messageServerId migration — **PR #6333 / `odi-17` follow-through**
2. **P0:** Discord plugin release blocked by publishing failure — **plugin-discord Issue #40**
3. **P1:** Telegram plugin crashes on photo/image handling — **plugin-telegram Issue #23**
4. **P1:** Cloud credit deduction TOCTOU race (streaming endpoints) — **(Linear-tracked)**
5. **P1:** Memory consumption / stability concerns — **elizaos/eliza Issue #6332**
6. **P2:** Parallel processing/throughput roadmap — **elizaos/eliza Issues #6334, #6337**
7. **P2:** plugin-discord unified API alignment (`handleMessage`) — **PR #41**
8. **P2:** Cloud API “model not found” docs + validation improvements — **(docs gap)**

---

## Patterns / Themes Indicating Deeper Issues
- **Schema evolution without a full compatibility contract:** The `serverId` → `messageServerId` rename surfaced how easily connector ecosystems break when core, bootstrap, and plugins are version-skewed.
- **Connector reliability is gating adoption:** Discord/Telegram issues dominate user-visible breakage; connectors need stronger test matrices and release discipline.
- **Scale + concurrency pressure is increasing:** TOCTOU billing races, memory growth, and parallelization discussions point to a need for explicit concurrency/ordering guarantees and soak testing.
- **Docs/UX gaps amplify support load:** “Model not found” and migration flags (`ELIZA_ALLOW_DESTRUCTIVE_MIGRATIONS`) repeatedly appear as avoidable friction.

---

## Process Improvements (to prevent repeats)
1. **Introduce a “Compatibility Matrix” CI lane**: test core + plugin-bootstrap + plugin-discord/plugin-telegram across the last 2 released versions (smoke tests for basic send/receive).
2. **Require deprecation windows for renamed fields**: support read-old/write-new for at least one minor release; add runtime warnings before removal.
3. **Release checklist + automated publish verification**: preflight job that validates tags, versions, tokens, and canary publishes to prevent plugin release blocks (Issue #40 class).
4. **Soak + stress tests for cloud invariants**: dedicated tests for billing/credits idempotency and streaming retries; add dashboards that detect TOCTOU regressions quickly.
5. **Improve “first-failure” error messages**: API validation that suggests correct model format; migration tooling that explains destructive migration flags and safe dev usage.