# Issue Triage — 2026-02-14 (elizaOS)

## 1) [Bug] URL in message triggers duplicate LLM calls — processed as both text and attachment (webapp) — **GH #6486**
- **Current Status:** Open (repro provided; needs owner + fix PR)
- **Impact Assessment:**
  - **User Impact:** High (anyone pasting URLs in web chat)
  - **Functional Impact:** Partial (core chat works, but double-runs)
  - **Brand Impact:** High (visible duplicated outputs + “wastes tokens” perception)
- **Technical Classification:**
  - **Category:** Bug / Performance (cost amplification)
  - **Component:** Webapp + Server message ingestion / attachment preview pipeline + SSE streaming aggregation
  - **Complexity:** Moderate effort (needs careful de-dupe + regression tests)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript; client SSE stream handling; server message pipeline; attachment/url preview logic
  - **Dependencies:** None, but should be tested alongside any attachment/preview generation logic
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P0**
- **Actionable Next Steps:**
  1. **Confirm root cause**: instrument where URL becomes both (a) text content and (b) attachment/preview payload.
  2. Add a **single “message normalization” decision point** before any LLM call: either treat URL as text or as attachment, not both.
  3. Add a **request-id / message-id idempotency guard** so only one LLM run can be associated with a user message.
  4. Add **integration test**: send message containing URL; assert exactly one model invocation; assert one streamed response before `done`.
  5. Add **cost regression** check (optional): ensure token usage doesn’t double with URL messages.
- **Potential Assignees:**
  - **lalalune** (core runtime/message flow familiarity)
  - **odilitime** (platform + message pipeline context)
  - **anchapin** (stability fixes; defensive guards pattern)

---

## 2) [Bug] roomId-related error prevents agent’s first post on X — **DISCORD-2026-02-13-roomId-x-post**
- **Current Status:** Unresolved (needs repro details; user awaiting diagnosis)
- **Impact Assessment:**
  - **User Impact:** Medium → High (blocks X/Twitter plugin onboarding for affected users)
  - **Functional Impact:** Yes (blocks “first post” for that integration path)
  - **Brand Impact:** Medium (integration reliability expectation)
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component:** Model Integration / Social plugin (X) + core message routing (room/world assumptions)
  - **Complexity:** Moderate effort (depends on mismatch between plugin expectations and runtime changes)
- **Resource Requirements:**
  - **Required Expertise:** Plugin integration; runtime identifiers (roomId/worldId); event/message creation path
  - **Dependencies:** Might intersect with “agents can respond without roomId/worldId” changes noted in v2 work; ensure v1/v2 parity
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P1**
- **Actionable Next Steps:**
  1. Request from reporter: runtime version, plugin version, logs/stack trace, config snippet, and whether using webapp/cloud/local.
  2. Identify whether failure occurs at **message creation**, **memory write**, or **plugin outbound call**.
  3. Add **fallback roomId creation** (or explicit error with remediation) when posting workflows start without a room context.
  4. Add a **smoke test** for “first post” flow in CI (mock X API) to prevent regressions.
- **Potential Assignees:**
  - **odilitime** (triage + runtime identifiers)
  - **lalalune** (core runtime changes; room/world behavior)
  - **azsxdc** (Twitter plugin user/integrator context; can help reproduce)

---

## 3) [Bug/Revenue] ElizaCloud account recharging fails for some users on VPN — **DISCORD-2026-02-11-cloud-vpn-recharge**
- **Current Status:** Open (acknowledged; needs concrete cases and fix)
- **Impact Assessment:**
  - **User Impact:** Medium (subset; but likely non-trivial given VPN usage)
  - **Functional Impact:** Yes (blocks payments/top-ups)
  - **Brand Impact:** High (billing friction + trust issues)
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component:** Cloud platform (billing/recharge flow), payment provider integration, fraud/risk controls
  - **Complexity:** Complex solution (payment edge-cases, risk scoring, provider constraints)
- **Resource Requirements:**
  - **Required Expertise:** Payments/billing integration; cloud backend; observability; possibly vendor support
  - **Dependencies:** Payment provider behavior; any WAF/rate-limit rules; geo/IP restrictions
  - **Estimated Effort (1–5):** 4
- **Recommended Priority:** **P0**
- **Actionable Next Steps:**
  1. Collect failing cases: timestamp, user region, VPN provider, HTTP status, provider error codes, client device/browser.
  2. Add **structured logging + trace IDs** around recharge attempts (server + provider callback).
  3. Verify whether failure is caused by **WAF**, **fraud rules**, **geo blocks**, or **session/cookie issues**.
  4. Implement **clear user-facing error messages** + recommended remediation (disable VPN / alternate method).
  5. If provider limitation: add an **alternate rail** (crypto top-up) or a “manual invoice” fallback for enterprise users.
- **Potential Assignees:**
  - **odilitime** (ElizaCloud owner; already engaged)
  - **borisudovicic** (cloud MVP planning; billing issues coordination)

---

## 4) [Bug/Abuse] Double account creation for same email grants $5 welcome bonus twice — **DISCORD-2026-02-11-cloud-welcome-bonus-dup**
- **Current Status:** Open (reported by user research; needs verification + hotfix)
- **Impact Assessment:**
  - **User Impact:** Medium (not all users, but directly impacts onboarding)
  - **Functional Impact:** Partial (system works but can be abused; accounting inconsistency)
  - **Brand Impact:** High (trust + promo abuse + perceived “buggy billing”)
- **Technical Classification:**
  - **Category:** Bug / Security (abuse) / Data integrity
  - **Component:** Cloud auth + user provisioning + promotions/credits ledger
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Cloud backend; auth/user model; database constraints; credits ledger design
  - **Dependencies:** Existing auth providers (email/OAuth) and how identities are linked
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P0**
- **Actionable Next Steps:**
  1. Reproduce: attempt repeated signups with same email across flows (magic link, OAuth, case/alias variants).
  2. Enforce **unique constraint** on canonicalized email (lowercase + provider normalization).
  3. Move welcome credit issuance to an **idempotent transaction** keyed by user identity.
  4. Add audit job: detect duplicates and reconcile credit balances.
  5. Add tests: “same email cannot create two accounts” + “welcome bonus issued once”.
- **Potential Assignees:**
  - **odilitime**
  - **borisudovicic**

---

## 5) [Feature/Platform] Add SIWE (EIP-4361) authentication to elizacloud + easy API key generation for agents — **DISCORD-2026-02-11-siwe-auth**
- **Current Status:** Planned/Committed (implementation in progress)
- **Impact Assessment:**
  - **User Impact:** High (unlocks agent-native onboarding and “proof-of-agent” workflows)
  - **Functional Impact:** Partial (cloud usable today, but this unblocks automation at scale)
  - **Brand Impact:** Medium → High (web3-native auth is expected given positioning)
- **Technical Classification:**
  - **Category:** Feature
  - **Component:** Cloud API/Auth; agent registration; credential management
  - **Complexity:** Complex solution (security-sensitive auth + key lifecycle)
- **Resource Requirements:**
  - **Required Expertise:** Auth/security; SIWE; key management; API gateway policies; threat modeling
  - **Dependencies:** Coordination with Privy (noted active collaboration) and existing JWT auth direction
  - **Estimated Effort (1–5):** 4
- **Recommended Priority:** **P1**
- **Actionable Next Steps:**
  1. Define auth modes: SIWE-only vs SIWE+JWT bridging; how keys map to entities/users.
  2. Implement SIWE nonce/session protection + replay defenses.
  3. Build agent flow: sign message → receive scoped API key → rotate/revoke.
  4. Add docs + SDK snippet for agents (TS/Python/Rust if possible).
  5. Add integration tests and rate limiting for registration endpoints.
- **Potential Assignees:**
  - **odilitime** (already committed)
  - **lalalune** (auth architecture alignment across runtimes)

---

## 6) [Security/Architecture] Memory “fake injection” risk in long-term storage — mitigations + guidance — **DISCORD-2026-02-13-memory-injection**
- **Current Status:** Open research item (acknowledged as broader LLM vuln; mitigation strategy not defined)
- **Impact Assessment:**
  - **User Impact:** Medium (depends on deployments that accept untrusted inputs)
  - **Functional Impact:** Partial (agents still run; but trust/integrity at risk)
  - **Brand Impact:** High if exploited publicly (agents “remembering” malicious content)
- **Technical Classification:**
  - **Category:** Security
  - **Component:** Memory subsystem; retrieval; long-term storage; plugin inputs
  - **Complexity:** Architectural change (mitigation is design-level, not a patch)
- **Resource Requirements:**
  - **Required Expertise:** LLM security; prompt-injection defenses; memory filtering; provenance and trust scoring
  - **Dependencies:** Memory schema and retrieval pipeline; any upcoming multi-tenant/auth isolation work
  - **Estimated Effort (1–5):** 5
- **Recommended Priority:** **P2**
- **Actionable Next Steps:**
  1. Review referenced research (Princeton) and summarize applicable threat models for elizaOS.
  2. Define “trusted vs untrusted memory sources” and tag memory entries with provenance.
  3. Add optional safeguards: quarantine suspicious memories, require confirmation before promoting to long-term, apply allowlist filters.
  4. Publish security guidance: recommended configs for public-facing agents (Discord/X/Moltbook).
- **Potential Assignees:**
  - **odilitime** (security triage + guidance)
  - **anchapin** (defensive patterns; runtime hardening)

---

## 7) [Feature] Support custom OpenAI endpoint URL for OpenAI provider — **GH #6490**
- **Current Status:** Open
- **Impact Assessment:**
  - **User Impact:** Medium (developers using OpenAI-compatible providers)
  - **Functional Impact:** Partial (blocks common self-hosted/3rd-party inference use cases)
  - **Brand Impact:** Medium (compatibility expectations)
- **Technical Classification:**
  - **Category:** Feature
  - **Component:** Model Integration (OpenAI provider config)
  - **Complexity:** Simple fix → Moderate effort (ensure it propagates across SDKs and doesn’t break defaults)
- **Resource Requirements:**
  - **Required Expertise:** Provider abstraction; config/env handling; docs
  - **Dependencies:** None; but should align with multi-language (TS/Python/Rust) provider parity if applicable
  - **Estimated Effort (1–5):** 2
- **Recommended Priority:** **P2**
- **Actionable Next Steps:**
  1. Add `baseURL` / `endpoint` configuration option (env + config file).
  2. Ensure safe default remains official OpenAI endpoint.
  3. Add docs + examples for SiliconFlow-style usage.
  4. Add unit test: requests go to configured baseURL.
- **Potential Assignees:**
  - **lalalune** (provider plumbing across runtimes)
  - **anchapin** (focused change + tests)

---

## 8) [Feature/Infra] Consolidate duplicate n8n plugins (plugin-n8n-workflow vs plugin-n8n) and standardize build/gen steps — **DISCORD-2026-02-12-n8n-consolidation**
- **Current Status:** Decision made verbally (use plugin-n8n-workflow); execution pending
- **Impact Assessment:**
  - **User Impact:** Medium (confusion + duplicated maintenance)
  - **Functional Impact:** No (both exist; but dev velocity suffers)
  - **Brand Impact:** Medium (repository sprawl + unclear “official”)
- **Technical Classification:**
  - **Category:** Documentation / Maintenance / UX (developer UX)
  - **Component:** Plugin System + CI/CD + repo governance
  - **Complexity:** Moderate effort (migration guidance + deprecation + CI updates)
- **Resource Requirements:**
  - **Required Expertise:** Repo admin; CI; plugin release process; documentation
  - **Dependencies:** Ensure crawl-script generation and CI release steps are documented and reproducible
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P2**
- **Actionable Next Steps:**
  1. Write a consolidation plan: which repo is canonical, deprecation notice, migration steps.
  2. Archive/delete the non-canonical repo (or mark read-only) and update registry/docs references.
  3. Add “local dev quickstart” explicitly covering the `crawl` generation step.
- **Potential Assignees:**
  - **standujar** (n8n-workflow owner/major contributor)
  - **Stan ⚡** (as referenced in discussions; plugin lead context)

---

## 9) [Docs/Product] Roadmap & positioning gaps for non-technical users (zero-code timeline, token utility, plugin recommendations, roadmap accessibility) — **DISCORD-2026-02-13-roadmap-noncoder**
- **Current Status:** Open (recurring community friction; not yet converted into concrete tracked deliverables)
- **Impact Assessment:**
  - **User Impact:** High (onboarding + investor/user expectations)
  - **Functional Impact:** Partial (product works; adoption and retention at risk)
  - **Brand Impact:** High (perception of “unclear direction”)
- **Technical Classification:**
  - **Category:** Documentation / UX
  - **Component:** ElizaCloud dashboard + docs + roadmap repo
  - **Complexity:** Moderate effort (content + light UI, but needs decisions)
- **Resource Requirements:**
  - **Required Expertise:** Product + docs; dashboard UX; roadmap governance
  - **Dependencies:** Requires alignment on actual planned milestones (payments, plugin marketplace, zero-code capabilities)
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P1**
- **Actionable Next Steps:**
  1. Convert discussion items into **roadmap issues** with owners and dates (even if “TBD”).
  2. Publish a **“Who is ElizaCloud for today?”** page (coders vs non-coders; what works without plugins).
  3. Add a **“Recommended safe plugins”** curated list in dashboard and docs.
  4. Create a **non-coder roadmap view** (milestones + plain-language outcomes).
- **Potential Assignees:**
  - **odilitime** (roadmap + cloud leadership)
  - **borisudovicic** (MVP/launch coordination; product framing)

---

# Conclusion

## A) Top 5–10 highest-priority issues to address immediately
1. **P0 — GH #6486:** URL messages trigger **duplicate LLM calls** (cost + UX regression).
2. **P0 — Cloud VPN recharge failures:** billing/top-up blocked for some users (revenue + trust).
3. **P0 — Cloud duplicate account + double $5 bonus:** abuse + accounting integrity risk.
4. **P1 — roomId blocks first X post:** breaks a key integration onboarding path.
5. **P1 — SIWE auth + agent API key flow:** unlocks agent-native onboarding and scaling.
6. **P1 — Roadmap/positioning docs for non-coders:** reduces churn and repeated support load.
7. **P2 — Memory injection mitigations/guidance:** security posture improvement (design-level).
8. **P2 — Custom OpenAI endpoint (GH #6490):** broad compatibility win with low effort.
9. **P2 — n8n plugin consolidation:** reduces confusion + maintenance overhead.

## B) Patterns/themes suggesting deeper architectural problems
- **Message identity/idempotency gaps:** Both the **URL double-processing** and the **roomId integration failures** point to inconsistent assumptions about what uniquely defines a message/run and what context (room/world) is required.
- **Cloud onboarding + billing fragility:** Repeated friction around **recharge flows**, **welcome bonus**, and “how to add USD” indicates missing guardrails, clearer UX, and stronger backend invariants.
- **Security posture is outpacing guidance:** The community is already concerned about **memory integrity**, but there’s no clear recommended deployment profile for public agents (Discord/X/marketplaces).
- **Repo/plugin sprawl:** Duplicate n8n repos and generated-file build confusion signal the need for tighter governance and “single source of truth” practices.

## C) Process improvement recommendations
- **Introduce a “cost regression” CI check** for common chat inputs (URLs, attachments) to detect accidental double-invocations early.
- **Enforce PR scope discipline:** large mixed-scope PRs increase rollback risk—require feature flags or separate PRs for architectural additions vs bugfixes.
- **Standardize runtime invariants:** define and document when `roomId/worldId` are mandatory vs optional; add contract tests for plugins.
- **Cloud incident loop:** add structured error codes, dashboards, and a lightweight incident template for billing/auth issues (with reproducible case capture).
- **Convert Discord action items into tracked GitHub issues** with owners, priority, and acceptance criteria to prevent “known but unowned” work.