## Issue Triage — 2026-01-24

### 1) ElizaCloud login intermittently fails with “Application error: a server-side exception has occurred”
- **Issue Title & ID:** ElizaCloud server-side exception prevents login (Discord: 2026-01-22 / #💬-discussion)
- **Current Status:** Reported by multiple users; intermittent; temporary relief via hard refresh; no root cause published.
- **Impact Assessment:**
  - **User Impact:** **High** (multiple users report inability to log in)
  - **Functional Impact:** **Yes** (blocks core hosted product access)
  - **Brand Impact:** **High** (hosted platform reliability perception)
- **Technical Classification:**
  - **Issue Category:** Bug / Reliability
  - **Component Affected:** API / Web App (ElizaCloud)
  - **Complexity:** Moderate effort (likely backend exception + frontend error handling/observability)
- **Resource Requirements:**
  - **Required Expertise:** Next.js/React + backend (Node/TS), observability (Sentry/log aggregation), infra familiarity
  - **Dependencies:** Access to production logs, deploy history, error tracking; ability to reproduce with affected accounts/regions
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Add/verify error tracking and correlation IDs for login and session creation paths.
  2. Pull server logs for the exact timestamps of reports; identify top exception signatures.
  3. Reproduce with cold cache + multiple browsers; test hard refresh “fix” hypothesis (stale asset/session mismatch).
  4. Add user-facing “retry + status” handling (graceful fallback) while root cause is fixed.
  5. Post a status update + workaround in Discord; open a GitHub issue in `elizaos/eliza` (or ElizaCloud repo) with stack traces once identified.
- **Potential Assignees:** **Kenk** (cloud/product), **0xbbjoker** (backend reliability), **odilitime** (core/platform), plus on-call infra owner if defined.

---

### 2) Discord plugin: DMs still broken; role provider errors “User has no name or username, skipping.”
- **Issue Title & ID:** Discord DM failures after plugin update; role provider skips users with missing username (Discord: 2026-01-23 / #💬-coders)
- **Current Status:** Server functionality restored by updating to `@elizaos/plugin-discord` **v1.3.8**; DM path still erroring.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (anyone relying on DMs / onboarding flows)
  - **Functional Impact:** **Partial** (guild channels work; DMs impaired)
  - **Brand Impact:** **Medium** (integration quality)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Plugin System → **Discord plugin** (role provider / DM pipeline)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Discord API nuances (DM user objects), plugin-discord internals, runtime entity/user mapping
  - **Dependencies:** Ability to reproduce with a DM-only test bot; fixtures for “no username” user payloads; Discord.js version compatibility
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Capture the raw Discord user payload in failing DMs (is it missing `username`, `global_name`, or `displayName`?).
  2. Update role provider to derive a stable identifier (user ID) even when display names are absent; avoid skipping.
  3. Add tests for DM events with minimal user fields; ensure entity initialization works in DM contexts.
  4. Publish a patch release (v1.3.9) and a short migration note.
- **Potential Assignees:** **0xbbjoker** (recently debugged plugin), **odilitime** (core/runtime + providers), **YuriNachos** (runtime robustness work).

---

### 3) Discord plugin regression: “Cannot access invalid private field (evaluating 'this.#conversationLength')” / proxy binding bug
- **Issue Title & ID:** recentMessagesProvider private field access error (Discord: 2026-01-22; fixed by plugin-discord v1.3.8)
- **Current Status:** **Resolved** for servers by upgrading to **v1.3.8**; ensure fix is documented and backported if needed.
- **Impact Assessment:**
  - **User Impact:** **High** (was preventing bots from responding)
  - **Functional Impact:** **Yes** (when present)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Plugin System → Discord plugin (message provider runtime binding)
  - **Complexity:** Simple fix (already implemented), but needs prevention work
- **Resource Requirements:**
  - **Required Expertise:** JS private fields, proxy method binding, bundling/transpilation
  - **Dependencies:** Regression test coverage in plugin repo
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2** (post-fix hardening)
- **Specific Actionable Next Steps:**
  1. Add a regression test that instantiates provider methods through the same proxy path that previously broke `#private` fields.
  2. Update docs/README: “Known good versions: elizaos 1.7.2 + plugin-discord 1.3.8”.
  3. Add runtime startup warning when plugin/core version mismatch is detected.
- **Potential Assignees:** **0xbbjoker**, **odilitime**

---

### 4) DB migration / adapter selection confusion (PGLite vs Postgres) causing schema creation failures
- **Issue Title & ID:** Runtime attempts PGLite path despite Postgres config; `CREATE SCHEMA IF NOT EXISTS migrations` failures (Discord: 2026-01-21/22)
- **Current Status:** Workarounds found (update to elizaos **1.7.2**, drop DB, reinstall; switch to **Neon**); underlying detection/config precedence risk remains.
- **Impact Assessment:**
  - **User Impact:** **Medium** (hits new/self-hosted developers)
  - **Functional Impact:** **Yes** (blocks local setup and deployments)
  - **Brand Impact:** **Medium** (developer experience)
- **Technical Classification:**
  - **Issue Category:** Bug / UX (configuration)
  - **Component Affected:** Core Framework + plugin-sql / runtime migrator
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** plugin-sql adapters (PGLite/PG/Neon), env precedence, migrator behavior
  - **Dependencies:** Repro steps with clean env; confirm interaction with `dotenv` precedence and existing `.eliza/.elizadb` state
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a GitHub issue in `elizaos/eliza` with a minimal repro matrix (PGLite→PG switch, existing dataDir present, env set/unset).
  2. Add explicit startup logging: chosen adapter, reason, and which env vars were read.
  3. Provide a CLI command to “reset db state” that also clears lingering adapter metadata.
  4. Docs: “How to migrate from PGLite to Postgres/Neon” with the exact safe steps.
- **Potential Assignees:** **standujar** (SQL/plugin depth), **wtfsayo** (plugin-sql reliability), **0xbbjoker** (env/config + DB work)

---

### 5) Website/dashboard data discrepancy: “Untracked repositories” table has twice as many columns as “Tracked repositories”
- **Issue Title & ID:** Untracked repos table schema mismatch (Reported in dev log: 2026-01-23; GitHub issue number not provided)
- **Current Status:** Newly reported; not triaged.
- **Impact Assessment:**
  - **User Impact:** **Low–Medium** (affects contributors/maintainers using analytics)
  - **Functional Impact:** **Partial** (UI/data correctness)
  - **Brand Impact:** **Medium** (public-facing dashboards reflect quality)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Docs/Website pipeline (`elizaos/elizaos.github.io`) and/or API summaries
  - **Complexity:** Moderate effort (schema alignment + data generation)
- **Resource Requirements:**
  - **Required Expertise:** Next.js site, data pipeline that generates summary JSON, table rendering components
  - **Dependencies:** Identify source of truth for tracked vs untracked repo schemas
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Open/locate the GitHub issue in `elizaos/elizaos.github.io` and attach a screenshot + expected schema.
  2. Trace the data model for both tables; unify column definitions and add type checks.
  3. Add a CI assertion validating table column counts against schema.
- **Potential Assignees:** **madjin** (site pipeline fixes), **ChristopherTrimboli** (site maintenance)

---

### 6) Migration security: scams asking users to “send tokens for migration”; lack of canonical guidance
- **Issue Title & ID:** Migration scam/social engineering confusion (Discord: 2026-01-22; repeated warnings 2026-01-23)
- **Current Status:** Team/community confirms scam; guidance exists in chat but not pinned/canonical.
- **Impact Assessment:**
  - **User Impact:** **High** (financial loss risk)
  - **Functional Impact:** **Partial** (doesn’t break code, but breaks safe usage)
  - **Brand Impact:** **High** (trust/safety)
- **Technical Classification:**
  - **Issue Category:** Security / Documentation
  - **Component Affected:** Migration portal UX + official comms/docs
  - **Complexity:** Simple fix (docs + UX), moderate if adding portal warnings/anti-phishing measures
- **Resource Requirements:**
  - **Required Expertise:** Security comms, web UX, Discord moderation playbooks
  - **Dependencies:** Ability to update migration portal banner and Discord pins; official announcement channels
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Publish a single canonical “Migration Safety” page: **“We will never ask you to send tokens to migrate.”**
  2. Add a prominent warning banner on the migration portal + link to the canonical page.
  3. Pin the message across relevant Discord channels; add an AutoMod response for keywords (“migration”, “send tokens”, “support wallet”).
  4. Add a “report scam” workflow and template for moderators.
- **Potential Assignees:** **Kenk** (support process), **Odilitime** (official messaging), **Arceon** (security/mod), plus Discord mods.

---

### 7) Community-facing clarification gap: multiple tokens/airdrops confusion harming project credibility (GOLD/BAGS/CJFT context)
- **Issue Title & ID:** Lack of clear official announcements and token relationship docs (Discord: 2026-01-23 / #💬-discussion, #🥇-partners)
- **Current Status:** High controversy; partial clarification in chat; no single authoritative post referenced.
- **Impact Assessment:**
  - **User Impact:** **High** (broad community confusion; potential financial harm)
  - **Functional Impact:** **No** (not a code failure)
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** Documentation / UX (communications)
  - **Component Affected:** Project comms, docs site, announcements process
  - **Complexity:** Moderate effort (needs coordination + canonical artifacts)
- **Resource Requirements:**
  - **Required Expertise:** Product/communications, governance, docs editing
  - **Dependencies:** Agreement on messaging and token taxonomy
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a “Token & Ecosystem Map” doc: what is ElizaOS vs project-specific tokens; what is/not official; where CAs are published.
  2. Establish an “Official Announcements Checklist” (pre-announce, CA publication timing, LP details, risk statement).
  3. Pin the doc; link from the docs site and Discord welcome.
- **Potential Assignees:** **Odilitime**, **Kenk**, **shaw** (for token context), **madjin** (docs site integration)

---

### 8) V2 PR risk: dynamic execution engine (PR #6384) flagged with critical Python implementation bugs
- **Issue Title & ID:** V2 dynamic execution engine — Python path correctness issues (GitHub PR: `elizaos/eliza` **#6384**, open)
- **Current Status:** PR open; review tooling flags Python runtime errors; not yet merged.
- **Impact Assessment:**
  - **User Impact:** **Low (today)** / **High (for V2 readiness)** (affects upcoming release, not current stable)
  - **Functional Impact:** **Partial** (blocks V2 quality; could break Python runtime users if merged)
  - **Brand Impact:** **Medium** (release stability)
- **Technical Classification:**
  - **Issue Category:** Bug / Architectural change
  - **Component Affected:** Core Framework (V2 runtime across TS/Rust/Python)
  - **Complexity:** Complex solution (cross-language parity + tests)
- **Resource Requirements:**
  - **Required Expertise:** Python runtime internals, schema/validation pipeline, streaming, cross-language API parity
  - **Dependencies:** Unit/integration tests for Python execution path; agreement on state model and templating
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P2** (unless V2 milestone is imminent → then escalate to P1)
- **Specific Actionable Next Steps:**
  1. Add Python-focused test coverage for `dynamic_prompt_exec_from_state` (callable prompt invocation, XML parsing, state access patterns).
  2. Fix reported Python issues (state wrapping, attribute access, XML regex limitations) and document expected state shape.
  3. Require cross-language conformance tests (same schema → same normalized output expectations).
- **Potential Assignees:** **odilitime** (author), **matomoniwano** (Python core work), **revlentless** (runtime architecture peer)

---

## Top Priority Summary (address immediately)
1. **P0:** ElizaCloud login server-side exceptions blocking access (Discord report).
2. **P0:** Migration scam prevention via canonical docs + portal/Discord warnings (Security/Docs).
3. **P1:** Discord plugin DM failures (“User has no name or username”) causing DM/onboarding breakage.
4. **P1:** DB migration/adapter selection confusion (PGLite vs Postgres/Neon) blocking developer setups.
5. **P1:** Official ecosystem/token clarification docs to reduce brand damage and user confusion.
6. **P2:** Dashboard/site data discrepancy: untracked vs tracked repo table schema mismatch.
7. **P2:** Harden Discord plugin private-field regression with tests and version-mismatch warnings (post-fix).
8. **P2:** V2 dynamic execution engine PR (#6384) — fix Python correctness issues before merge.

---

## Patterns / Themes Suggesting Deeper Issues
- **Insufficient release hardening for plugins:** The Discord private-field regression and DM edge cases suggest missing integration tests that simulate real runtime wiring (proxy/binding) and “minimal payload” Discord objects.
- **Configuration and state precedence pitfalls:** Repeated confusion around DB adapters (PGLite vs PG) indicates the system lacks transparent “chosen configuration” diagnostics and safe migration tooling.
- **Operational maturity gap in hosted product:** Intermittent ElizaCloud failures + “hard refresh fixes” point to missing observability, error budgets, and incident workflows.
- **Trust & safety depends on ad-hoc chat responses:** Migration scam mitigation and token clarity are happening via Discord replies rather than durable, linkable canonical documentation.

---

## Process Recommendations (to prevent recurrence)
1. **Add “Known Good Versions” + compatibility checks**: At runtime startup, detect mismatched `@elizaos/core` vs plugin versions and emit a clear warning with upgrade instructions.
2. **Introduce end-to-end plugin CI scenarios**: For Discord/Telegram, run a minimal simulated event pipeline (including DMs) with fixtures for missing/optional fields and verify responses.
3. **Improve configuration transparency**: Log “effective config” (selected DB adapter, resolved env precedence, dataDir usage) and provide a single CLI reset/migrate command.
4. **Operationalize ElizaCloud reliability**: Standardize incident triage (Sentry + dashboards + on-call rotation), publish a lightweight status page, and add regression checks for auth/session flows.
5. **Canonical security/comms artifacts**: Maintain a pinned “Security & Migration” page and an “Official Contract Addresses / Announcements” policy so users never rely on screenshots or rumors.