## Issue Triage — 2026-01-25

### 1) ElizaCloud intermittent “Application error: a server-side exception has occurred” prevents login
- **Issue Title & ID:** ElizaCloud login intermittently fails with server-side exception (DISCORD-2026-01-22-ELIZACLOUD-500)
- **Current Status:** Reported by multiple users; intermittent; temporary workaround via hard refresh; no linked GitHub issue found (needs one).
- **Impact Assessment:**
  - **User Impact:** **High** (blocks access for multiple users)
  - **Functional Impact:** **Yes** (Cloud login is core)
  - **Brand Impact:** **High** (public-facing outage)
- **Technical Classification:**
  - **Issue Category:** Bug / Reliability
  - **Component Affected:** Cloud App / API / Frontend
  - **Complexity:** Moderate effort (likely requires logs + repro + fix + deploy)
- **Resource Requirements:**
  - **Required Expertise:** Web ops, Next.js/React, backend API debugging, observability/logging
  - **Dependencies:** Access to production logs/alerts; ability to correlate with deploys
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create a GitHub issue in `elizaos/eliza` (or Cloud repo if separate) with timestamps, affected routes, and user reports.
  2. Pull server logs for failing requests (status codes, stack traces) and correlate with deploy SHA and time window.
  3. Add/verify request ID tracing from client → edge → API to pinpoint failure layer.
  4. Implement a graceful error boundary + retry guidance in UI (reduce “dead end” page).
  5. Add an uptime check + alerting for login endpoint and session creation.
- **Potential Assignees:** `wtfsayo` (infra/CI & reliability), `0xbbjoker` (backend stability), `madjin` (web/app), plus Cloud ops owner (if distinct).

---

### 2) Token migration scam actively targeting users (fraudulent “support” DM asking to send tokens)
- **Issue Title & ID:** Active migration scam: “send ai16z to wallet for manual migration” (DISCORD-2026-01-24-SEC-MIGRATION-SCAM)
- **Current Status:** Reported; acknowledged as known pattern; response in chat was ambiguous; no canonical “official migration never requires sending tokens” pinned doc linked everywhere.
- **Impact Assessment:**
  - **User Impact:** **Critical** (direct user fund loss)
  - **Functional Impact:** **Partial** (not code execution, but affects onboarding/migration flow)
  - **Brand Impact:** **High** (trust/safety)
- **Technical Classification:**
  - **Issue Category:** Security / UX / Documentation
  - **Component Affected:** Community support surface, migration portal messaging, docs
  - **Complexity:** Simple fix (comms + guardrails), Moderate if adding portal protections
- **Resource Requirements:**
  - **Required Expertise:** Security triage, community moderation, web copy updates
  - **Dependencies:** Discord mod permissions; website/docs update pipeline
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Publish an **official security bulletin**: “We will never ask you to send tokens to migrate.” Include known scam address(es) and reporting instructions.
  2. Pin message in key Discord channels; add AutoMod response for keywords (“migration”, “support”, “send tokens”, address patterns).
  3. Add banner/notice on migration portal (`migrate.elizafoundation.ai`) reinforcing the rule.
  4. Provide a single official support path (ticket form) and link it everywhere.
  5. Establish a “verified staff” DM policy: staff should not initiate migration DMs.
- **Potential Assignees:** `Odilitime` (core/community responses), `wtfsayo` (web workflow updates), `madjin` (site/banner), Discord moderators (non-GitHub).

---

### 3) Discord plugin DM failures: role provider error “User has no name or username, skipping”
- **Issue Title & ID:** Discord DMs failing due to missing username in role provider (DISCORD-2026-01-23-DISCORD-DM-ROLEPROVIDER)
- **Current Status:** Server functionality improved after updating to `@elizaos/plugin-discord@1.3.8`, but DM issues persist for some users.
- **Impact Assessment:**
  - **User Impact:** Medium–High (affects common DM use cases)
  - **Functional Impact:** **Partial** (Discord agent still works in servers for many)
  - **Brand Impact:** Medium (plugin reliability perception)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Plugin System → Discord plugin (roles/provider pipeline)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Discord API semantics (users vs members), TS debugging, plugin-bootstrap provider expectations
  - **Dependencies:** Repro case (DM event payload where user lacks username/display name)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Capture raw DM event payloads for failing users and compare to working cases.
  2. Update provider logic to fall back to `user.globalName`, `user.id`, or `author.tag` equivalents; avoid hard skip.
  3. Add tests covering DM events with missing/empty username fields.
  4. Publish a patch release of plugin-discord and note DM fix explicitly in changelog.
- **Potential Assignees:** `odilitime` (plugin-bootstrap/provider conventions), `0xbbjoker` (Discord plugin troubleshooting).

---

### 4) Discord plugin/core mismatch produced “Cannot access invalid private field (#conversationLength)” in recentMessagesProvider (regression risk)
- **Issue Title & ID:** recentMessagesProvider private field access error blocks responses (DISCORD-2026-01-22-DISCORD-RECENTMESSAGES-PRIVATEFIELD)
- **Current Status:** Reported as critical on 1.7.2 upgrade; community confirms update to `plugin-discord@1.3.8` resolves server functionality; still needs a postmortem + compatibility guard.
- **Impact Assessment:**
  - **User Impact:** High (breaks bots on upgrade path)
  - **Functional Impact:** **Yes** (agent fails to respond)
  - **Brand Impact:** High (upgrade instability)
- **Technical Classification:**
  - **Issue Category:** Bug / Compatibility
  - **Component Affected:** Plugin System (Discord plugin + core runtime/provider contracts)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** TS runtime internals, provider interface versioning, release engineering
  - **Dependencies:** Identify exact version combos that fail; add peer-dep constraints
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Document a **compatibility matrix** for core `@elizaos/*` and `@elizaos/plugin-discord` versions.
  2. Add runtime startup check: detect incompatible plugin/core versions and emit a clear error with upgrade command.
  3. Add regression test in plugin-discord CI pinned to latest core and N-1 core.
- **Potential Assignees:** `0xbbjoker` (upgrade triage), `odilitime` (core/plugin contract changes).

---

### 5) CLI upgrade path confusion: CLI remains on 1.6.5 after upgrading to 1.7.2; SQL migration failures due to cached references
- **Issue Title & ID:** CLI version conflict + migration failures after upgrading 1.6.5 → 1.7.2 (DISCORD-2026-01-24-CLI-CACHE-VERSION)
- **Current Status:** Workaround provided and confirmed (bun cache + reinstall + clean lockfiles + update package.json).
- **Impact Assessment:**
  - **User Impact:** Medium (hits upgraders; likely common)
  - **Functional Impact:** **Partial** (blocks bootstrap/migrations until fixed)
  - **Brand Impact:** Medium (perceived fragility)
- **Technical Classification:**
  - **Issue Category:** UX / Documentation / Tooling bug
  - **Component Affected:** CLI / Package management
  - **Complexity:** Simple fix (docs + better detection), Moderate if tooling changes
- **Resource Requirements:**
  - **Required Expertise:** Bun package behavior, CLI packaging, DX documentation
  - **Dependencies:** Reproduce with bun global installs + cached templates
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2** (upgrade friction, but workaround exists)
- **Specific Actionable Next Steps:**
  1. Add a CLI command `eliza doctor` to detect mismatched core/CLI/plugin versions and cached template versions.
  2. Update official upgrade guide with the exact bun commands (cache rm, reinstall, clean lockfiles).
  3. Consider pinning/validating template `package.json` versions during `eliza init` and `eliza upgrade`.
- **Potential Assignees:** `YuriNachos` (CLI robustness), `0xbbjoker` (DX + migrations), `odilitime` (release consistency).

---

### 6) Database migration error: “CREATE SCHEMA IF NOT EXISTS migrations” failing on some Postgres providers (Aiven/pgvector image mismatch)
- **Issue Title & ID:** Postgres migration schema creation fails on some managed DBs; Neon works (DISCORD-2026-01-22-SQL-MIGRATIONS-SCHEMA)
- **Current Status:** User unblocked by switching to Neon; root cause not fully documented; risk of recurring support load.
- **Impact Assessment:**
  - **User Impact:** Medium (affects specific DB setups, but blocks those users completely)
  - **Functional Impact:** **Yes** (DB migrations gate agent startup)
  - **Brand Impact:** Medium–High (setup pain)
- **Technical Classification:**
  - **Issue Category:** Bug / Documentation
  - **Component Affected:** `plugin-sql` migrator / DB compatibility layer
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Postgres permissions/extensions, Drizzle migrator behavior, pgvector/managed DB quirks
  - **Dependencies:** Repro on Aiven (or similar) + confirm required permissions
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1** (blocks setups; likely to recur)
- **Specific Actionable Next Steps:**
  1. Reproduce on Aiven with minimal schema permissions; identify which role lacks `CREATE` on schema / database.
  2. Update migrator to either:
     - avoid schema creation when not needed, or
     - fall back to public schema, or
     - provide a clear permission error with required SQL grants.
  3. Add DB provider compatibility notes (Neon/Aiven/Supabase/local) to docs.
- **Potential Assignees:** `standujar` (plugin-sql), `0xbbjoker` (DB/migrations), `wtfsayo` (runtime crash prevention).

---

### 7) V2 dynamic execution engine PR has critical Python implementation bugs flagged in review tooling (risk before wider adoption)
- **Issue Title & ID:** V2 dynamic prompt exec: Python runtime callable/state/template bugs (PR elizaos/eliza **#6384**, open)
- **Current Status:** PR open; greptile review flags Python-breaking issues (state wrapping, template substitution assumptions, XML regex not matching underscores).
- **Impact Assessment:**
  - **User Impact:** Medium (primarily V2 early adopters, but growing)
  - **Functional Impact:** **Partial** (V2 pathway; could break Python runtime)
  - **Brand Impact:** Medium (quality perception of V2)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** V2 Runtime (Python) / Structured output validation & streaming
  - **Complexity:** Complex solution (cross-language parity, tests)
- **Resource Requirements:**
  - **Required Expertise:** Python runtime internals, schema/structured parsing, streaming extraction
  - **Dependencies:** Agreement on canonical State structure across TS/Rust/Python
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1** (prevent shipping broken V2 Python path)
- **Specific Actionable Next Steps:**
  1. Add Python unit tests covering: callable prompt invocation, protobuf State access, XML fields with underscores.
  2. Fix callable invocation to pass state consistently (no `{ "state": state }` mismatch).
  3. Replace `dir()`-based attribute discovery with explicit dict/protobuf-safe accessors.
  4. Update XML parsing regex to support underscores and nested tags robustly.
- **Potential Assignees:** `odilitime` (author), `matomoniwano` (Python work), with review from `0xbbjoker`.

---

### 8) Tokenomics strategy ambiguity causing ecosystem trust issues (needs a canonical technical + product narrative)
- **Issue Title & ID:** Clarify relationship between $elizaos and ecosystem tokens + utility linkage (DISCORD-2026-01-24-TOKENOMICS-CLARITY)
- **Current Status:** High community tension; competing proposals (airdrops/pairing/grants); technical proposal exists (fees/burns for compute & storage).
- **Impact Assessment:**
  - **User Impact:** High (community/investor confidence; onboarding)
  - **Functional Impact:** No (not a runtime blocker)
  - **Brand Impact:** **High** (project legitimacy perception)
- **Technical Classification:**
  - **Issue Category:** Documentation / Product / Architecture (token utility integration)
  - **Component Affected:** Ecosystem design, Cloud billing/fees, developer platform guidance
  - **Complexity:** Architectural change (if implementing protocol-level fees)
- **Resource Requirements:**
  - **Required Expertise:** Product strategy, token utility modeling, Cloud billing/metrics, smart contract design (if on-chain)
  - **Dependencies:** Decision from core leadership; alignment with upcoming Cloud apps launch
  - **Estimated Effort:** **5/5** (if implementing; **2/5** for doc-only)
- **Recommended Priority:** **P1** for documentation + decision record; **P2** for implementation planning
- **Specific Actionable Next Steps:**
  1. Publish an RFC: “Ecosystem tokens policy” (when allowed, disclosures, holder alignment).
  2. Define a minimal utility bridge: Cloud compute/storage fees payable in $elizaos (even if off-chain metering initially).
  3. Add a disclosure checklist for any team-associated launches (wallet distribution, LP policy, vesting, audits).
- **Potential Assignees:** `shaw` (decision owner, non-GitHub), `odilitime` (technical RFC), `madjin` (docs site), `standujar` (billing/DB implications if metering stored).

---

## Summary: Top 5–10 highest priority issues to address immediately
1. **P0:** ElizaCloud intermittent login/server-side exception (DISCORD-2026-01-22-ELIZACLOUD-500)
2. **P0:** Active token migration scam mitigation (DISCORD-2026-01-24-SEC-MIGRATION-SCAM)
3. **P1:** Discord DM role provider failures (DISCORD-2026-01-23-DISCORD-DM-ROLEPROVIDER)
4. **P1:** Discord plugin/core compatibility guardrails to prevent private-field regression (DISCORD-2026-01-22-DISCORD-RECENTMESSAGES-PRIVATEFIELD)
5. **P1:** Postgres migration schema creation failures across DB providers (DISCORD-2026-01-22-SQL-MIGRATIONS-SCHEMA)
6. **P1:** V2 dynamic execution engine Python breakages before merge/adoption (PR #6384)
7. **P1:** Tokenomics/ecosystem-token relationship clarity RFC + comms (DISCORD-2026-01-24-TOKENOMICS-CLARITY)
8. **P2:** CLI upgrade/version caching confusion; add “doctor” + upgrade docs (DISCORD-2026-01-24-CLI-CACHE-VERSION)

---

## Patterns / Themes indicating deeper issues
- **Versioning & compatibility drift across core/CLI/plugins:** Repeated Discord upgrade failures point to missing automated compatibility checks and clearer peer dependency constraints.
- **Operational maturity gaps for Cloud:** Intermittent “server-side exception” plus reliance on “hard refresh” suggests missing observability, error boundaries, and health monitoring.
- **Onboarding safety and trust as a product surface:** Migration scams and token confusion show that docs, pinned notices, and portal UI are part of the security boundary.
- **DB/provider fragmentation:** Setup failures vary by Postgres provider; docs and migrator logic need explicit compatibility contracts.

---

## Process improvement recommendations
1. **Ship a compatibility matrix + automated runtime checks** (core ↔ plugin versions) and fail fast with actionable upgrade commands.
2. **Introduce a single “Known Issues / Incidents” page** (Cloud + migration + plugins) and link it from CLI output and Discord pins.
3. **Add Cloud observability baselines:** request IDs, structured logging, Sentry (or equivalent), uptime checks for login/session endpoints.
4. **Standardize “Security Comms” playbook:** pre-written templates, pinned Discord posts, portal banners, and AutoMod keyword triggers.
5. **DB provider certification:** maintain a short list of tested Postgres providers with required grants/extensions; add CI smoke tests for at least Neon + local Postgres + PGLite.