## Issue Triage — 2026-01-30

### 1) Action callbacks execute in reverse order + structured return omitted (Eliza 1.7.2) — **Discord: 💬-coders (Victor Creed) | Needs GH issue**
- **Current Status:** Reported on Discord; no fix/workaround confirmed; appears unresolved.
- **Impact Assessment:**
  - **User Impact:** High (affects anyone building custom actions/plugins using callbacks; explicitly hits `plugin-sql`, `plugin-openai`, `plugin-bootstrap`)
  - **Functional Impact:** **Yes** (breaks documented action UX + possibly breaks downstream automation relying on structured return)
  - **Brand Impact:** High (core framework behavior contradicts docs; visible message ordering regressions)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Core Framework (message service / action execution / callback handling)
  - **Complexity:** Moderate effort (may involve async scheduling, streaming, or message dispatch queue ordering)
- **Resource Requirements:**
  - **Required Expertise:** Core runtime/message pipeline; async/streaming semantics; plugin action lifecycle
  - **Dependencies:** Need a minimal repro (ideally in an example project) and confirmation whether it’s 1.7.2-only regression vs earlier
  - **Estimated Effort:** 4/5
- **Recommended Priority:** **P0**
- **Actionable Next Steps:**
  1. Open a GitHub issue in `elizaos/eliza` with a minimal repro (action that emits: initial feedback → structured return → callback detail).
  2. Add automated test to assert message ordering and presence of structured return.
  3. Bisect recent changes around message streaming / multi-step workflows / callback dispatch.
  4. Patch: enforce deterministic ordering (queue/await) and ensure structured return is emitted.
  5. Release a 1.7.x patch and add a migration note if behavior changed intentionally.
- **Potential Assignees:** **odilitime** (core/CLI), **0xbbjoker** (core/plugin-sql), **wtfsayo** (infra/CI), with Victor Creed providing repro validation.

---

### 2) `Cannot find module '@elizaos/plugin-web-search'` after installation — **Discord: 💬-discussion (DigitalDiva) | Needs GH issue**
- **Current Status:** Workaround suggested (package.json/module resolution + try `bun`); root cause not confirmed.
- **Impact Assessment:**
  - **User Impact:** Medium–High (blocks common “web search” capability; likely frequent for newcomers)
  - **Functional Impact:** Partial (plugin-specific, but a very common plugin)
  - **Brand Impact:** High (plugin install failures are a top onboarding friction)
- **Technical Classification:**
  - **Issue Category:** Bug / UX (packaging + install experience)
  - **Component Affected:** Plugin System / Packaging (exports, moduleResolution, build artifacts)
  - **Complexity:** Simple fix to Moderate (depends on whether it’s exports/build/publish error)
- **Resource Requirements:**
  - **Required Expertise:** Node/Bun packaging, TS build outputs, `exports` field, monorepo publishing
  - **Dependencies:** Reproduce on Node vs Bun; verify published package contents
  - **Estimated Effort:** 2–3/5
- **Recommended Priority:** **P1**
- **Actionable Next Steps:**
  1. Reproduce in a clean starter project (`@elizaos/cli` create → add plugin).
  2. Inspect `@elizaos/plugin-web-search` npm package: verify `main`, `types`, `exports`, and built files exist.
  3. Fix packaging/publish pipeline (ensure dist is included; correct `exports` map).
  4. Add docs snippet: correct install/import pattern + supported runtimes (bun/node) until fixed.
- **Potential Assignees:** **odilitime** (packaging/CLI), **YuriNachos** (runtime robustness), **sayonara/wtfsayo** (docs + CI checks).

---

### 3) OpenRouter embeddings unreliable / only OpenAI works in Knowledge plugin — **Discord: 2026-01-28 highlights (YogaFlame, jin) | Needs GH issue**
- **Current Status:** Multiple user reports; acknowledged that Ollama/OpenAI/OpenRouter are “supported,” but OpenRouter failing in practice.
- **Impact Assessment:**
  - **User Impact:** High (knowledge/RAG is a flagship capability; embeddings provider failures cripple it)
  - **Functional Impact:** **Yes** for users choosing OpenRouter (blocks knowledge ingestion/search)
  - **Brand Impact:** High (provider instability feels like “it only works with OpenAI”)
- **Technical Classification:**
  - **Issue Category:** Bug / Integration
  - **Component Affected:** Model Integration / Knowledge Plugin (embeddings path)
  - **Complexity:** Moderate (provider-specific API quirks, headers, dimensions, rate limits, error handling)
- **Resource Requirements:**
  - **Required Expertise:** embeddings APIs, OpenRouter compatibility, plugin-knowledge architecture, logging/telemetry
  - **Dependencies:** Capture representative failing requests/responses; confirm model + endpoint used
  - **Estimated Effort:** 4/5
- **Recommended Priority:** **P1**
- **Actionable Next Steps:**
  1. Create GH issue with logs: provider config, model name, HTTP status/body, and minimal reproduction doc.
  2. Add better error surfacing (include provider response + actionable hints).
  3. Add integration test that runs an embeddings call against a mocked OpenRouter-compatible endpoint.
  4. If OpenRouter behavior differs (dimensions, response schema), implement adapter normalization.
  5. Publish a “known-good configs” matrix (OpenAI/Ollama/OpenRouter).
- **Potential Assignees:** **jin** (tracking + infra), **0xbbjoker** (knowledge/sql depth), **YogaFlame** (reporter/validation), **odilitime** (core integration direction).

---

### 4) Knowledge plugin misconfiguration: `EMBEDDING_PROVIDER='openrouter'` invalid enum (`openai | google`) — **GH: elizaos/eliza #? (not provided) + Discord 2026-01-27**
- **Current Status:** Users hit validation error; workaround is “set provider to openai.” Indicates docs/config mismatch.
- **Impact Assessment:**
  - **User Impact:** High (common setup path; blocks startup)
  - **Functional Impact:** Partial (configuration validation blocks knowledge features; may block runtime init)
  - **Brand Impact:** High (confusing “supported providers” vs enum validation)
- **Technical Classification:**
  - **Issue Category:** Documentation + UX (config schema mismatch)
  - **Component Affected:** Knowledge Plugin / Config validation
  - **Complexity:** Simple fix (docs/schema alignment) to Moderate (if provider list actually intended to include OpenRouter)
- **Resource Requirements:**
  - **Required Expertise:** config schema ownership, docs, knowledge plugin roadmap (v2.x “embeddings to plugins”)
  - **Dependencies:** Decide intended truth: is OpenRouter supported as provider or only as model routing to OpenAI?
  - **Estimated Effort:** 2/5
- **Recommended Priority:** **P1**
- **Actionable Next Steps:**
  1. Clarify canonical config: `EMBEDDING_PROVIDER=openai` + optional `OPENROUTER_EMBEDDING_MODEL=...` (if that’s the supported path).
  2. Update docs + `.env.example` + validation error text to explicitly guide users.
  3. If OpenRouter should be first-class, extend enum + implement provider adapter fully.
- **Potential Assignees:** **0xbbjoker** (knowledge behavior), **sayonara** (docs), **odilitime** (core config conventions).

---

### 5) ETH-chain token swap shows ~98% loss due to zero liquidity; unclear migration path — **Discord: 💬-discussion (Sarthak) | Needs Docs + Ops ticket**
- **Current Status:** Users directed to “migration channel”; no canonical, linkable instructions surfaced in the conversation.
- **Impact Assessment:**
  - **User Impact:** Medium–High (affects ETH-side holders; financially painful)
  - **Functional Impact:** Partial (not framework-core, but ecosystem-critical)
  - **Brand Impact:** **Critical** (users perceive it as a broken/unsafe migration)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX (and potentially ecosystem ops/liquidity)
  - **Component Affected:** Migration Portal / Token Ops / Docs site
  - **Complexity:** Moderate (writing clear steps is easy; resolving liquidity/mechanics may be complex/operational)
- **Resource Requirements:**
  - **Required Expertise:** Migration ops, onchain liquidity mechanics, support escalation playbook
  - **Dependencies:** Confirm official intended path (bridge? portal? deadline? supported wallets?)
  - **Estimated Effort:** 2/5 for docs; 5/5 if liquidity remediation is required
- **Recommended Priority:** **P0** (brand + user harm)
- **Actionable Next Steps:**
  1. Publish a single canonical “ETH-chain holders” guide (docs + pinned Discord) with explicit do/don’t (e.g., “do not market-sell on illiquid pool”).
  2. Add portal banner/FAQ addressing liquidity and recommended migration flow.
  3. Provide an escalation path for stuck users (form + expected SLA).
- **Potential Assignees:** **Hexx 🌐** (community comms), **Odilitime** (official messaging), **sayonara** (docs PRs), plus a designated migration-ops owner.

---

### 6) Migration portal fails to detect balances in certain wallets (Phantom / hardware wallets) — **Theme from Discord 2026-01-28; related closed GH: elizaos/eliza #6369**
- **Current Status:** Tangem case (#6369) closed via manual intervention; new reports for Phantom detection failures persist.
- **Impact Assessment:**
  - **User Impact:** Medium (subset of holders, but repeated)
  - **Functional Impact:** Partial (migration eligibility/detection breaks)
  - **Brand Impact:** High (migration trust issues)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Migration Portal (wallet connectors + snapshot lookup)
  - **Complexity:** Moderate (wallet connector differences; snapshot indexing; chain/account formats)
- **Resource Requirements:**
  - **Required Expertise:** Web3 wallet integration, snapshot data pipeline, portal frontend
  - **Dependencies:** Need reproducible wallet cases + logs; define supported wallet list clearly
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P1**
- **Actionable Next Steps:**
  1. Open/track a single “Portal balance detection issues” GH issue aggregating Phantom/Tangem edge cases.
  2. Add “manual claim” workflow with verification checklist to reduce ad-hoc support load.
  3. Improve portal debug view: show which address/account is queried and snapshot source used.
- **Potential Assignees:** **jin** (tracking systems), a portal maintainer (not named in provided data), **Hexx 🌐** for comms.

---

### 7) SSE streaming setup causes `MIME_TYPE_MISMATCH`; users switching to socket.io — **Discord: 2026-01-28 (sedano.npc, Chucknorris) | Needs GH issue**
- **Current Status:** Workaround is “use socket.io”; root cause is backend deployment/config mismatch.
- **Impact Assessment:**
  - **User Impact:** Medium (affects anyone deploying SSE behind certain proxies/hosts)
  - **Functional Impact:** Partial (streaming broken; chat still may work non-streaming)
  - **Brand Impact:** Medium (perceived instability in recommended transport)
- **Technical Classification:**
  - **Issue Category:** Bug / Documentation
  - **Component Affected:** Server API / Streaming transports (SSE)
  - **Complexity:** Moderate (content-type headers, proxy buffering, CORS, route handling)
- **Resource Requirements:**
  - **Required Expertise:** server transport layer, deployment (nginx/vercel/fly/railway), HTTP headers
  - **Dependencies:** Identify hosting environments that trigger mismatch; add deployment guidance
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P2**
- **Actionable Next Steps:**
  1. Document supported transports by environment (SSE vs socket.io) and required proxy config.
  2. Add a healthcheck endpoint/test script to validate SSE headers end-to-end.
  3. Improve server error message with detected `Content-Type` and expected value.
- **Potential Assignees:** **wtfsayo** (server/CI), **odilitime** (core/server), **Chucknorris** (validation in real deployments).

---

### 8) Integrate N8N workflow engine as primary automation layer — **GH: elizaos/eliza #6429**
- **Current Status:** Open; defined acceptance criteria; positioned as “P0 - Core Architecture” in issue body.
- **Impact Assessment:**
  - **User Impact:** Medium (strategic feature; not a current break/failure)
  - **Functional Impact:** No (not required for existing core runtime), but **high leverage** for roadmap
  - **Brand Impact:** Medium (delivers “agent does real work” narrative)
- **Technical Classification:**
  - **Issue Category:** Feature Request
  - **Component Affected:** Plugin System / Workflow Automation / Cloud execution
  - **Complexity:** Architectural change (multi-tenant OAuth + workflow execution + storage)
- **Resource Requirements:**
  - **Required Expertise:** n8n internals, OAuth multi-tenancy, cloud deployment, secure credential storage
  - **Dependencies:** OAuth Gateway layer; storage per user/tenant; execution environment choice (hosted vs self-host)
  - **Estimated Effort:** 5/5
- **Recommended Priority:** **P2** (unless leadership explicitly declares it sprint-critical over stability work)
- **Actionable Next Steps:**
  1. Break into sub-issues: workflow generation, node discovery, credential binding, execution, persistence, security review.
  2. Define MVP: “generate JSON + run on hosted n8n with single-tenant credentials” vs full multi-tenant.
  3. Add threat model for credential storage + least-privilege node execution.
- **Potential Assignees:** **Stan ⚡** (n8n plugin work), **sam** (cloud runtime integration), **borisudovicic** (issue owner/product), **Shaw (s)** (architecture direction).

---

### 9) Social connection page + Composio-based in-chat authentication — **Discord: core-devs (sam, Stan) | Needs GH issue(s)**
- **Current Status:** Planned; existing `plugin-composio` exists externally; RFC pending.
- **Impact Assessment:**
  - **User Impact:** Medium (improves onboarding + integrations)
  - **Functional Impact:** Partial (blocks certain integration flows until shipped)
  - **Brand Impact:** Medium (polish and professionalism)
- **Technical Classification:**
  - **Issue Category:** Feature / UX
  - **Component Affected:** Cloud / Auth / Plugin System
  - **Complexity:** Moderate to Complex (OAuth redirect flows + session binding + security)
- **Resource Requirements:**
  - **Required Expertise:** OAuth, web app auth, secure token handling, plugin integration patterns
  - **Dependencies:** Decision: Composio vs bespoke; RFC review; connection-page hosting in cloud
  - **Estimated Effort:** 4/5
- **Recommended Priority:** **P2**
- **Actionable Next Steps:**
  1. Convert to GH epic + tasks: (a) connection page, (b) redirect + bot resume token, (c) Composio plugin adoption, (d) security review.
  2. Review Stan’s repo `github.com/standujar/plugin-composio` and upstream/port as needed.
  3. Publish RFC and get sign-off on chosen auth approach.
- **Potential Assignees:** **sam** (connection UX), **Stan ⚡** (Composio plugin), **odilitime** (security + core integration).

---

## Top Highest-Priority Issues (Fix Immediately / This Sprint)
1. **P0:** Action callbacks reversed + structured return omitted (Eliza 1.7.2) — Discord 💬-coders (needs GH issue)
2. **P0:** ETH-chain swap/migration guidance gap causing massive perceived losses — Discord 💬-discussion (docs + ops)
3. **P1:** Knowledge plugin embeddings unreliable with OpenRouter — Discord reports (needs GH issue)
4. **P1:** Knowledge plugin config/schema mismatch for `EMBEDDING_PROVIDER` leading to startup failures — docs/schema alignment
5. **P1:** `@elizaos/plugin-web-search` module resolution/install failure — Discord 💬-discussion (needs GH issue)
6. **P1:** Migration portal balance detection failures (Phantom/hardware wallets) — recurring theme; related to closed #6369
7. **P2:** SSE `MIME_TYPE_MISMATCH` streaming deployment friction — docs + server improvements
8. **P2:** N8N integration epic (#6429) — roadmap-critical but should not preempt P0 stability unless mandated
9. **P2:** Social connection page + Composio auth integration — planned work; unblock integrations

---

## Patterns / Themes Indicating Deeper Issues
- **Async/message lifecycle determinism is brittle:** Callback ordering and missing structured outputs suggest concurrency/streaming refactors lack regression coverage.
- **Provider/config fragmentation:** “Supported provider” claims vs enum validation, plus OpenRouter embedding failures, indicate drifting contracts between docs, config schema, and adapters.
- **Onboarding reliability depends on packaging correctness:** Plugin install/module resolution issues remain a recurring “front door” risk.
- **Operational/docs gaps are creating existential trust issues:** Migration and liquidity confusion is dominating community perception and support load.

---

## Process Improvements (Prevent Recurrence)
1. **Add contract tests for action/callback messaging:** Golden tests that assert ordering + presence of structured returns across non-streaming and streaming paths.
2. **Introduce a “Known-Good Config” matrix + linting:** A CI-verified set of `.env` examples for common stacks (OpenAI/Ollama/OpenRouter; bun/node) and clearer validation errors pointing to fixes.
3. **Packaging smoke tests for every published plugin:** Automated install+import test in a fresh starter project (bun + node) before release.
4. **Single-source-of-truth operational docs with pinned links:** Especially for migration flows; publish canonical pages and ensure Discord helpers always link the same URL.
5. **Convert high-signal Discord bug reports into GH issues within 24 hours:** Establish a lightweight triage rotation to ensure reports don’t remain “tribal knowledge” in chat.