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

### 1) [Bug] URL in message triggers duplicate LLM calls — processed as both text and attachment (webapp) — **#6486**
- **Current Status:** OPEN (reported; needs confirmation + root-cause)
- **Impact Assessment:**
  - **User Impact:** **High** (any user sending URLs in chat; common behavior)
  - **Functional Impact:** **Partial** (core chat works, but responses duplicated + cost doubled)
  - **Brand Impact:** **High** (visible “broken” output + unexpected billing)
- **Technical Classification:**
  - **Category:** Bug / Performance
  - **Component Affected:** Webapp + Server streaming (SSE) + Message/Attachment processing pipeline
  - **Complexity:** Moderate effort (needs pipeline audit; likely small fix once found)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript, server message flow, SSE streaming, attachment enrichment/link-preview handling
  - **Dependencies:** Understand/confirm how URL metadata is represented (as attachment vs text); any link-preview service
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Reproduce with tracing enabled; log message “parts” before LLM call(s) and before streaming chunks.
  2. Identify the duplicate invocation point (e.g., text handler + attachment handler both calling LLM).
  3. Implement a single “content normalization” step: decide whether URL is handled as inline text OR attachment preview (not both).
  4. Add regression test: one user message with URL → exactly one LLM call, one streamed response, one `done`.
  5. Add metric/telemetry counter to detect double-invocation patterns in production.
- **Potential Assignees:** **lalalune** (runtime/message flow), **anchapin** (stability fixes), **odilitime** (integration oversight)

---

### 2) Consolidate duplicate n8n repos: **plugin-n8n-workflow** vs **plugin-n8n** (Discord core-devs action item)
- **Current Status:** In discussion; decision made informally to consolidate around **plugin-n8n-workflow** (needs execution plan)
- **Impact Assessment:**
  - **User Impact:** **Medium** (confuses builders; duplicated docs; split community support)
  - **Functional Impact:** **Partial** (doesn’t break runtime, but increases onboarding friction and support load)
  - **Brand Impact:** **Medium–High** (perceived chaos/duplication in ecosystem)
- **Technical Classification:**
  - **Category:** UX / Documentation / Maintenance
  - **Component Affected:** Plugin System + Repos/Registry + Docs
  - **Complexity:** Moderate effort (repo archival, redirects, docs updates, registry alignment)
- **Resource Requirements:**
  - **Required Expertise:** GitHub repo maintenance, release process, plugin registry, documentation
  - **Dependencies:** Confirm which package name(s) are canonical; ensure users can migrate cleanly
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a short decision note: canonical repo = `plugin-n8n-workflow`, `plugin-n8n` deprecated.
  2. Archive or delete the redundant repo (preferred: archive + README pointer first, then delete later).
  3. Update any plugin registry references, READMEs, and examples to the canonical plugin.
  4. If both are published packages: mark old one deprecated on npm and pin a final notice release.
- **Potential Assignees:** **standujar (Stan ⚡)** (primary maintainer), **odilitime** (ecosystem coordination), **s** (original consolidation prompt)

---

### 3) plugin-n8n-workflow local build fails due to missing generated JSON (`defaultNodes.json`, `schemaIndex.json`, `triggerSchemaIndex.json`) — (Discord core-devs)
- **Current Status:** Known behavior; files intentionally excluded; workaround = run `crawl` script (documentation exists but still causing confusion)
- **Impact Assessment:**
  - **User Impact:** **Medium** (any contributor/user trying to build locally hits a hard stop)
  - **Functional Impact:** **Partial** (blocks local dev; CI/release works)
  - **Brand Impact:** **Medium** (appears “broken to build”)
- **Technical Classification:**
  - **Category:** UX / Documentation / Build
  - **Component Affected:** Plugin build tooling + CI pipeline
  - **Complexity:** Simple fix (DX improvements) to Moderate (tooling changes)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript build tooling, CI workflows, developer experience
  - **Dependencies:** Align expectations: local dev vs CI generation; decide whether to auto-run crawl
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add a prebuild step that checks for generated JSON and prints a clear actionable error (“Run `bun run crawl`”).
  2. Add `postinstall` (optional) to prompt or optionally generate data (guarded by env flag to avoid surprise).
  3. Ensure README has a “Local Dev Quickstart” at the top with crawl/build sequence.
  4. Add CI check to ensure the error message stays accurate (snapshot/expected output).
- **Potential Assignees:** **standujar (Stan ⚡)**, **odilitime** (DX review)

---

### 4) ElizaCloud.ai billing/recharge fails for some users on VPN + unclear USD top-up flow (Discord: yojo research)
- **Current Status:** Reported by multiple non-coder testers; acknowledged; needs investigation + UX fixes
- **Impact Assessment:**
  - **User Impact:** **High** (blocks paying users from recharging; directly impacts revenue)
  - **Functional Impact:** **Yes** (payment/recharge is core for SaaS)
  - **Brand Impact:** **High** (payment friction destroys trust fast)
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component Affected:** ElizaCloud web dashboard + payments/billing integration
  - **Complexity:** Complex solution (payment provider behavior, VPN/risk checks, UI clarity)
- **Resource Requirements:**
  - **Required Expertise:** Web payments, fraud/risk controls, frontend UX, analytics
  - **Dependencies:** Payment provider logs; reproduce with VPN; define supported geo/VPN policy
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Collect concrete cases (timestamps, user agents, VPN provider, error codes) and pull provider logs.
  2. Add client-side error capture + correlation IDs for recharge attempts.
  3. Provide an in-product “How to add funds” guided flow (single CTA, step-by-step, confirm success state).
  4. Decide policy: “VPN supported” vs “VPN blocked”; communicate clearly in UI if blocked.
- **Potential Assignees:** **odilitime** (cloud lead), **yojo** (repro/user interviews), cloud/frontend maintainer(s) from core team

---

### 5) ElizaCloud welcome bonus bug: double account creation for single email + $5 bonus duplication (Discord: yojo research)
- **Current Status:** Reported; not yet tracked publicly as GH issue (should be filed)
- **Impact Assessment:**
  - **User Impact:** **High** (breaks onboarding; account confusion)
  - **Functional Impact:** **Yes** (identity/account integrity)
  - **Brand Impact:** **High** (looks like insecure/buggy billing/auth)
- **Technical Classification:**
  - **Category:** Bug / Security-adjacent (abuse potential) / UX
  - **Component Affected:** ElizaCloud auth + referral/crediting system + user DB constraints
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Auth flows, database constraints/idempotency, billing credits
  - **Dependencies:** Identify which identity provider is used (email magic link? OAuth?); current DB uniqueness rules
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create a tracked issue in the ElizaCloud repo with exact repro steps + screenshots.
  2. Enforce email uniqueness at DB level; make signup idempotent (same email → same user row).
  3. Make bonus crediting idempotent (one-time grant with transactional guard).
  4. Audit for existing duplicates; merge/resolve affected accounts; prevent further bonus abuse.
- **Potential Assignees:** **odilitime**, cloud backend owner, **yojo** (validation/testing)

---

### 6) Add SIWE (EIP-4361) authentication to ElizaCloud (Discord: commitment by Odilitime)
- **Current Status:** Planned/committed; not yet landed
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (enables agent-native auth + smoother API key provisioning)
  - **Functional Impact:** **Partial** (unblocks “proof-of-agent” onboarding concept; improves developer workflow)
  - **Brand Impact:** **Medium** (signals modern Web3 auth; reduces friction for agent ecosystem)
- **Technical Classification:**
  - **Category:** Feature
  - **Component Affected:** ElizaCloud auth/API key management
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** SIWE spec, nonce/session handling, API security, token issuance
  - **Dependencies:** Decide relationship to existing JWT auth (framework already added JWT support in core); align with Privy collaboration plans
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Define SIWE flow (nonce endpoint, domain binding, statement, expiration) + threat model.
  2. Implement signature verification + session/JWT issuance.
  3. Add “Generate API Key” UX for agents post-SIWE.
  4. Integration tests for replay protection + key rotation.
- **Potential Assignees:** **odilitime**, security-minded reviewer (from core team), **DorianD** (requirements)

---

### 7) Fix group chat functionality “currently not working” (Discord: action item from user **s**)
- **Current Status:** Reported; insufficient details; needs triage ticket with repro + logs
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (group chat is a common collaboration mode)
  - **Functional Impact:** **Partial** (direct messaging may still work)
  - **Brand Impact:** **High** (chat reliability is a core quality signal)
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component Affected:** Client (groups UI) + Server (rooms/groups APIs, sockets)
  - **Complexity:** Moderate effort (depends on failure mode)
- **Resource Requirements:**
  - **Required Expertise:** React client + server socket/io + DB models for rooms/groups
  - **Dependencies:** Need version info, deployment mode (self-hosted vs cloud), auth mode (JWT on/off)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Convert to a GitHub issue with required template fields (steps, expected/actual, logs, screenshots).
  2. Add automated E2E test for creating/joining group and sending messages (especially with JWT enabled).
  3. Identify if regression ties to recent auth/session isolation changes.
- **Potential Assignees:** **lalalune**, **anchapin**, client maintainer(s)

---

### 8) Babylon feedback: “share to farcaster” link displays incorrectly (Discord: Agent Joshua ₱ | TEE)
- **Current Status:** Reported; unanswered where feedback goes; needs owner confirmation
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects social sharing loop)
  - **Functional Impact:** **Partial** (feedback still possible; sharing broken)
  - **Brand Impact:** **Medium** (viral loop quality impacts perception)
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component Affected:** Babylon app integration (sharing link generation)
  - **Complexity:** Simple fix (likely URL encoding/template mismatch)
- **Resource Requirements:**
  - **Required Expertise:** Frontend share intents, Farcaster compose URL format, URL encoding
  - **Dependencies:** Identify which Babylon surface (web/mobile) and where link is generated
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Capture an example of the broken link + expected Farcaster intent.
  2. Add unit test for share-link builder with special characters.
  3. Confirm analytics: click-through rate and errors (if available).
- **Potential Assignees:** Babylon frontend owner (if known), **odilitime** (coordination)

---

### 9) Feature Request: Support custom OpenAI endpoint URL for OpenAI provider — **#6490**
- **Current Status:** OPEN
- **Impact Assessment:**
  - **User Impact:** **Medium** (unblocks OpenAI-compatible providers like SiliconFlow)
  - **Functional Impact:** **Partial** (core works with OpenAI; limits compatibility)
  - **Brand Impact:** **Medium** (developer experience and “provider openness”)
- **Technical Classification:**
  - **Category:** Feature Request
  - **Component Affected:** Model Integration (OpenAI provider configuration)
  - **Complexity:** Simple fix (config + plumbing) to Moderate (ensure consistent across runtimes)
- **Resource Requirements:**
  - **Required Expertise:** Provider abstraction, configuration/env handling, docs
  - **Dependencies:** Decide config key naming; ensure no security regression (SSRF concerns if running server-side)
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add `OPENAI_BASE_URL` (or provider-scoped config) and wire through client instantiation.
  2. Validate URL allowlist/format (especially in hosted/cloud contexts).
  3. Update docs + examples (SiliconFlow, OpenRouter-like, etc. where applicable).
- **Potential Assignees:** **lalalune** (core/provider architecture), model integration maintainer(s)

---

### 10) [Agent] Eliza Character File & Prompt Engineering — **#6447**
- **Current Status:** OPEN (iterative improvement)
- **Impact Assessment:**
  - **User Impact:** **Medium** (quality improvements visible to many)
  - **Functional Impact:** **No** (not a blocker; improves outcomes)
  - **Brand Impact:** **Medium–High** (assistant personality/quality is user-facing)
- **Technical Classification:**
  - **Category:** UX / Feature (content/prompting)
  - **Component Affected:** Default character/prompt templates; model configuration (Sonnet testing)
  - **Complexity:** Moderate effort (iterative testing + evaluation)
- **Resource Requirements:**
  - **Required Expertise:** Prompt engineering, evaluation harness/scenarios, cost/perf awareness
  - **Dependencies:** Planned PRs for examples/model switch (mentioned in issue)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Define measurable criteria (helpfulness, refusal behavior, consistency) and add scenario tests where possible.
  2. Incorporate message examples (as per referenced PRs) and run A/B against target models.
  3. Track cost impact (tie into scenario cost evaluator work that just closed in #5759).
- **Potential Assignees:** **borisudovicic** (issue owner), contributor working on model swap PR(s), **monilpat** (evaluation mindset)

---

## Summary — Top highest-priority issues to address now (next 24–72 hours)
1. **#6486 URL causes duplicate LLM calls** (P0) — doubles cost + breaks responses; affects core chat UX.
2. **ElizaCloud VPN recharge failure** (P0) — blocks revenue; major trust hit.
3. **ElizaCloud welcome bonus/account duplication bug** (P0) — identity integrity + potential abuse.
4. **Consolidate n8n plugin repos** (P1) — reduces confusion + support burden; ecosystem hygiene.
5. **plugin-n8n-workflow “missing JSON” local build friction** (P1) — ongoing contributor onboarding failure.
6. **Group chat not working (reported)** (P1) — core collaboration feature; needs concrete repro + fix path.
7. **SIWE for ElizaCloud** (P1) — unlocks agent-native onboarding + API key provisioning.
8. **Babylon “share to farcaster” link bug** (P2) — impacts growth loop; easy win.
9. **#6490 custom OpenAI base URL** (P2) — improves compatibility with OpenAI-like providers.

## Patterns / Themes Indicating Deeper Issues
- **Message pipeline duplication & event lifecycle ambiguity:** #6486 suggests the system lacks a single normalized “message parts → one inference pass” contract, especially when attachments/link previews exist.
- **Developer experience gaps due to generated artifacts:** n8n JSON generation is correct architecturally, but repeated confusion indicates missing guardrails (preflight checks, clearer errors, automated generation options).
- **Cloud onboarding/payment reliability as primary risk surface:** Multiple independent UX/payment issues (VPN recharge + double account creation) point to insufficient idempotency, observability, and “non-coder” guided flows.
- **Ecosystem fragmentation (duplicate repos, 1.x vs 2.x):** Consolidation and version-bridging tooling are becoming necessary to avoid splitting user attention and breaking confidence.

## Process Improvement Recommendations
1. **Adopt “Idempotency + uniqueness by default” for Cloud:** enforce DB constraints, idempotent credit grants, and request IDs for billing actions.
2. **Introduce a “Message Processing Contract” doc + tests:** define one canonical flow for text + attachments + link previews; add regression tests for “one user input → one LLM run.”
3. **DX preflight checks for generated assets:** add build-time validators that fail fast with actionable instructions; consider optional auto-generation in dev.
4. **Ecosystem hygiene policy:** require a deprecation plan for duplicate plugins/repos (archive + redirects + registry updates + final deprecating release).
5. **Triage intake discipline:** convert Discord-reported breakages (group chat, payments, Farcaster share) into GitHub issues within 24 hours with required repro templates and owner assignment.