## Issue Triage — 2026-01-23

### 1) ElizaCloud login intermittently fails with “Application error: a server-side exception has occurred”
- **Issue Title & ID:** ElizaCloud intermittent server-side exception blocks login (DISCORD-2026-01-22-CLOUD-LOGIN-ERROR)
- **Current Status:** **Open / Untriaged** (multiple user reports; intermittent; hard refresh sometimes temporarily helps)
- **Impact Assessment:**
  - **User Impact:** **High** (multiple users affected; prevents platform access)
  - **Functional Impact:** **Yes** (blocks login / core cloud usage)
  - **Brand Impact:** **High** (public “app error” at login severely harms trust)
- **Technical Classification:**
  - **Issue Category:** Bug / Reliability
  - **Component Affected:** ElizaCloud (Web App + API), Auth/session layer likely
  - **Complexity:** Moderate effort (depends on observability + root cause)
- **Resource Requirements:**
  - **Required Expertise:** Web/API debugging, auth/session, Sentry/logging, infra/ops
  - **Dependencies:** Need access to production logs, deploy history, error traces; may depend on DB health
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Add/verify error tracking (Sentry or equivalent) on login route and session refresh endpoints; capture correlation IDs.
  2. Pull production logs for timestamps matching user reports; identify dominant exception class + failing endpoint.
  3. Reproduce with fresh session + hard refresh flow; test across browsers and with/without cached assets.
  4. Add a status-page note + in-app fallback message if backend is degraded (avoid generic “Application error”).
  5. Publish a short incident update in Discord once root cause is identified (reduces support load).
- **Potential Assignees:** **odilitime** (platform), **standujar** (DB/infra adjacency), **0xbbjoker** (backend triage), plus an ops maintainer with deploy access

---

### 2) Discord agent stops responding after v1.7.2 with recentMessagesProvider private-field error
- **Issue Title & ID:** `recentMessagesProvider` throws “Cannot access invalid private field … #conversationLength” (DISCORD-2026-01-22-DISCORD-RECENTMESSAGES-PRIVATEFIELD)
- **Current Status:** **Open / Under investigation** (reported by users; 0xbbjoker investigating)
- **Impact Assessment:**
  - **User Impact:** **High** (Discord is a primary integration; affects many deployments)
  - **Functional Impact:** **Yes** (agent fails to respond in channels and DMs)
  - **Brand Impact:** **High** (appears as “bot is broken” after update)
- **Technical Classification:**
  - **Issue Category:** Bug / Compatibility
  - **Component Affected:** Plugin System → **plugin-discord** (and/or core message provider interfaces)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** TypeScript, Discord plugin internals, message providers, build tooling/transpilation nuances around private fields
  - **Dependencies:** Confirm exact plugin-discord version(s) + node runtime; may depend on bundler output and class fields compilation target
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create a minimal reproduction using v1.7.2 + plugin-discord v1.3.7 and capture stack trace + compiled output location.
  2. Verify whether `#conversationLength` is being accessed across module boundaries or on a differently-constructed instance (common private-field failure mode).
  3. Audit recentMessagesProvider implementation for `#privateField` usage; replace with `protected/public` field or accessor if cross-package access is required.
  4. Add a regression test in plugin-discord for recent message retrieval + DM response path.
  5. Ship a patch release (plugin-discord v1.3.8 or core patch) and pin recommended versions in docs.
- **Potential Assignees:** **0xbbjoker** (primary), **odilitime** (core/provider contract), **standujar** (review/testing rigor)

---

### 3) Token migration scam attempts: users told to “send tokens to a wallet for migration”
- **Issue Title & ID:** Migration scam/social engineering risk; clarify official migration flow (DISCORD-2026-01-22-MIGRATION-SCAM-WALLET)
- **Current Status:** **Open** (confirmed scam in community; needs preventative comms + UX hardening)
- **Impact Assessment:**
  - **User Impact:** **Critical** (direct user fund-loss risk)
  - **Functional Impact:** **Partial** (migration can proceed, but users may be tricked)
  - **Brand Impact:** **High** (scams attributed to project if not proactively addressed)
- **Technical Classification:**
  - **Issue Category:** Security / Documentation / UX
  - **Component Affected:** Migration portal UX + Support processes + Community comms
  - **Complexity:** Simple fix (comms) + Moderate (portal UX improvements)
- **Resource Requirements:**
  - **Required Expertise:** Security-minded comms, web UX, Discord moderation, support operations
  - **Dependencies:** None; portal changes may require deploy cycle
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Post a pinned Discord announcement: “Migration never requires sending tokens to any wallet address.”
  2. Add a prominent banner on the migration portal reiterating the same and linking to official support channel/ticketing.
  3. Publish an “official links” page and enforce link hygiene (only those links are ever used by mods/support).
  4. Create an abuse-report intake (Google form or ticket tag) to collect scam wallet addresses for public warning/blacklist messaging.
- **Potential Assignees:** **Kenk** (support/comms), **Arceon** (mod/security), **odilitime** (portal banner), **madjin** (site/docs placement)

---

### 4) Migration eligibility breaks when users transfer from wallets without dApp browsers (e.g., Robinhood) or hardware wallets
- **Issue Title & ID:** Migration eligibility mismatch after wallet transfers / hardware wallet snapshot discrepancies (Theme: elizaos/eliza#6369 + DISCORD-2026-01-22-MIGRATION-ELIGIBILITY-TRANSFER)
- **Current Status:** **Partially mitigated** (support tickets can resolve; recurring user confusion)
- **Impact Assessment:**
  - **User Impact:** **High** (common user flow; centralized wallets/hardware wallets are frequent)
  - **Functional Impact:** **Partial** (migration possible, but blocked without manual intervention)
  - **Brand Impact:** **High** (seen as “migration is broken/unfair”)
- **Technical Classification:**
  - **Issue Category:** Bug / UX / Supportability
  - **Component Affected:** Migration portal eligibility logic + snapshot reconciliation tooling
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** On-chain snapshot tooling, portal backend, support workflow automation
  - **Dependencies:** Access to snapshot dataset + deterministic eligibility rules; may require policy decisions (what evidence is accepted)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Document “transferred after snapshot” and “CEX/no dApp browser” scenarios with a step-by-step official remedy.
  2. Add a self-serve “eligibility dispute” flow: collect snapshot address + current address + proof tx hashes; auto-queue for review.
  3. Build an internal admin tool/script to lookup snapshot balances by address and apply overrides with audit logs.
  4. Add portal messaging when “not eligible” that explicitly routes users to the dispute flow (reduces Discord churn).
- **Potential Assignees:** **odilitime** (portal/backend), **standujar** (data pipeline/validation), **Kenk** (support workflow design)

---

### 5) PostgreSQL migrations failing with `CREATE SCHEMA IF NOT EXISTS migrations` (provider/adapter confusion; Aiven vs Neon)
- **Issue Title & ID:** Postgres migration fails / adapter selection confusion (DISCORD-2026-01-22-DB-MIGRATIONS-CREATE-SCHEMA)
- **Current Status:** **Workaround found** (switching to Neon); underlying compatibility unclear
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (affects self-hosters; blocks DB-backed deployments)
  - **Functional Impact:** **Yes** (blocks persistence; prevents boot)
  - **Brand Impact:** **Medium** (feels fragile and “hard to self-host”)
- **Technical Classification:**
  - **Issue Category:** Bug / Documentation
  - **Component Affected:** plugin-sql (pg vs managed providers), migrations runner, pgvector compatibility notes
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Postgres permissions/schema, Drizzle migrations, managed Postgres platforms (Aiven/Neon), pgvector
  - **Dependencies:** Need reproducible environment matrix (Aiven, local docker, Neon)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Determine root cause: permission issue vs connection role vs migration runner assumptions (schema creation privileges).
  2. Add a preflight check: verify `CREATE SCHEMA` privilege and surface a clear error message with remediation SQL.
  3. Document “known-good Postgres providers” and required extensions/permissions; include an Aiven-specific guide if supported.
  4. Add CI smoke test against at least one managed Postgres target (or an equivalent restrictive role simulation).
- **Potential Assignees:** **standujar** (SQL/migrations), **0xbbjoker** (DB adapter debugging), **odilitime** (docs + runtime behavior)

---

### 6) Telegram plugin crashes on image processing (TypeError)
- **Issue Title & ID:** Telegram plugin image processing TypeError (elizaos-plugins/plugin-telegram#23)
- **Current Status:** **Open** (reported as crashing bug)
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects Telegram deployments using images)
  - **Functional Impact:** **Partial** (core chat may work; image handling crashes)
  - **Brand Impact:** **Medium** (plugin instability perception)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** plugin-telegram (media pipeline)
  - **Complexity:** Simple fix to Moderate effort (depends on upstream API changes)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript, Telegram Bot API media handling, runtime error handling
  - **Dependencies:** Need failing payload sample; may depend on Telegram API response formats
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Capture the exact stack trace and failing message payload (redact secrets).
  2. Add defensive guards + content-type checks; avoid crashing the whole handler.
  3. Add a unit/integration test with fixture payloads for image messages.
- **Potential Assignees:** **0xbbjoker** (plugin alignment), **standujar** (review), issue reporter **GarrickBrown** for reproduction validation

---

### 7) Discord plugin runtime error: undefined message functions
- **Issue Title & ID:** Discord plugin runtime error (undefined message functions) (elizaos-plugins/plugin-discord#43)
- **Current Status:** **Open** (reported; likely separate from private-field regression but may overlap in symptom “bot doesn’t respond”)
- **Impact Assessment:**
  - **User Impact:** **High** (Discord deployments commonly used)
  - **Functional Impact:** **Yes/Partial** (depending on code path)
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** Bug / Integration
  - **Component Affected:** plugin-discord message handling layer
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** plugin-discord internals, message adapter contracts, version compatibility
  - **Dependencies:** Confirm interaction with core 1.7.2 and plugin-discord 1.3.7+; may be fixed by same patch as Issue #2
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Correlate with Issue #2: determine if this is a separate bug or downstream symptom.
  2. Add contract tests for message handler function presence during plugin initialization.
  3. Ensure plugin exports/types are aligned with core expectations; tighten runtime asserts with actionable errors.
- **Potential Assignees:** **0xbbjoker**, **odilitime**

---

### 8) SQL “zero vector fallback” error (embedding/vector edge case)
- **Issue Title & ID:** SQL error related to zero-vector fallback (elizaos/eliza#6380)
- **Current Status:** **Open** (reported)
- **Impact Assessment:**
  - **User Impact:** **Medium** (hits users with embeddings edge cases / missing vectors)
  - **Functional Impact:** **Partial** (impacts search/retrieval; may break requests)
  - **Brand Impact:** **Medium** (quality/performance perception)
- **Technical Classification:**
  - **Issue Category:** Bug / Reliability
  - **Component Affected:** plugin-sql (vector search / embeddings)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Postgres + pgvector, query design, fallback semantics
  - **Dependencies:** Confirm expected behavior when embedding is missing/zero; may touch query building
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Reproduce with empty/zero embedding inputs and capture the exact SQL error.
  2. Define consistent fallback: skip vector filter, or use deterministic sentinel vector with safe similarity semantics.
  3. Add regression tests across pg/neon/pglite where applicable.
- **Potential Assignees:** **standujar**, **0xbbjoker**

---

### 9) Dashboard bug (details unspecified) impacting app experience
- **Issue Title & ID:** Dashboard bug (elizaos/eliza#6382)
- **Current Status:** **Open / Needs clarification**
- **Impact Assessment:**
  - **User Impact:** **Medium** (dashboard is user-facing; scope unknown)
  - **Functional Impact:** **Partial** (depends on bug; could block common flows)
  - **Brand Impact:** **Medium–High** (UI bugs are visible)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** GUI/Dashboard (ElizaCloud web client)
  - **Complexity:** Simple fix (if localized) to Moderate (if systemic state issue)
- **Resource Requirements:**
  - **Required Expertise:** Frontend (React/Next), API-client contracts, UI state management
  - **Dependencies:** Need reproduction steps/screenshots
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Request/collect reproduction steps, browser console logs, and affected route.
  2. Triage whether it relates to the login/server-side exceptions (Issue #1) or is independent.
  3. Add a minimal e2e regression test once fixed.
- **Potential Assignees:** **borisudovicic** (product/UX triage), **odilitime** (platform), **madjin** (web pipeline familiarity)

---

### 10) GitHub org hygiene: outdated `.cursor` repo appears in elizaOS repos list (7 months old)
- **Issue Title & ID:** Outdated `.cursor` repository listed under elizaOS org; needs transfer/removal (DISCORD-2026-01-22-REPO-HYGIENE-CURSOR)
- **Current Status:** **Open**
- **Impact Assessment:**
  - **User Impact:** **Low** (mostly affects contributors browsing org)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (signals clutter / poor hygiene)
- **Technical Classification:**
  - **Issue Category:** Documentation / Process
  - **Component Affected:** GitHub org management
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** GitHub org admin permissions
  - **Dependencies:** Confirm ownership and whether any workflows depend on it
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Confirm it is unused and not referenced by CI/docs.
  2. Transfer to personal account or archive; remove from org listing if possible.
  3. Add a lightweight “org hygiene” monthly checklist.
- **Potential Assignees:** **jin** (reported), org admin maintainer, **madjin** (web/API awareness)

---

## Highest-Priority Focus List (Top 5–10 to address immediately)
1. **P0:** ElizaCloud login intermittent server-side exception (DISCORD-2026-01-22-CLOUD-LOGIN-ERROR)  
2. **P0:** Discord plugin recentMessagesProvider private-field crash and non-responsiveness (DISCORD-2026-01-22-DISCORD-RECENTMESSAGES-PRIVATEFIELD)  
3. **P0:** Migration scam prevention (DISCORD-2026-01-22-MIGRATION-SCAM-WALLET)  
4. **P1:** Migration eligibility mismatches after transfers/hardware wallets (Theme: #6369 + DISCORD-2026-01-22-MIGRATION-ELIGIBILITY-TRANSFER)  
5. **P1:** Discord plugin undefined message functions (elizaos-plugins/plugin-discord#43)  
6. **P1:** Postgres migrations `CREATE SCHEMA` failures / provider compatibility (DISCORD-2026-01-22-DB-MIGRATIONS-CREATE-SCHEMA)  
7. **P2:** Telegram image processing crash (elizaos-plugins/plugin-telegram#23)  
8. **P2:** plugin-sql zero-vector fallback error (elizaos/eliza#6380)  
9. **P2:** Dashboard bug (elizaos/eliza#6382)  
10. **P3:** GitHub org repo hygiene: `.cursor` repo cleanup (DISCORD-2026-01-22-REPO-HYGIENE-CURSOR)

---

## Patterns / Themes Suggesting Deeper Issues
- **Regression risk across plugin boundaries:** Discord failures indicate fragile contracts (private fields, undefined functions) and insufficient cross-version integration tests between **@elizaos/core** and plugins.
- **Operational maturity gap on the hosted product:** Intermittent login exceptions + lack of a clear ticketing/support entrypoint suggests missing incident response tooling and customer-facing status/triage flow.
- **DB portability/documentation gaps:** Users switching providers (Aiven → Neon) to “fix” migrations indicates uneven support across managed Postgres offerings and insufficient preflight diagnostics.
- **Security surface is partly social, not just code:** Migration scams show that documentation and UX guardrails are as critical as smart contracts/backends.

---

## Process Improvement Recommendations
1. **Add a “Release Compatibility Matrix”** (core version ↔ plugin versions ↔ minimum Node version) and enforce it via CI, especially for Discord/Telegram.
2. **Introduce end-to-end smoke tests for top integrations** (Discord: channel + DM; Telegram: text + image) that run on every core or plugin release tag.
3. **Production incident loop for ElizaCloud:**
   - error tracking + structured logs + correlation IDs
   - a simple public status indicator
   - a documented escalation path + ticketing link surfaced in-app
4. **DB preflight checks & actionable errors:** Detect missing privileges/extensions and print remediation SQL instead of failing deep in migrations.
5. **Security-by-default comms:** Maintain a pinned “Official Links & Never Do This” post and mirror it on the migration portal; rotate scam warnings as needed.