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

### 1) [Bug] URL in message triggers duplicate LLM calls — processed as both text and attachment (webapp) — elizaos/eliza #6486
- **Current Status:** OPEN (1 comment)
- **Impact Assessment:**
  - **User Impact:** High (any webapp user sending links)
  - **Functional Impact:** Partial (responses still arrive, but duplicated; cost + UX regression)
  - **Brand Impact:** High (visible “broken/duplicated output” and wasteful API usage)
- **Technical Classification:**
  - **Issue Category:** Bug / Performance
  - **Component Affected:** Webapp + Server message pipeline (SSE stream), Attachment/link preview handling
  - **Complexity:** Moderate effort (requires tracing message normalization + attachment extraction path)
- **Resource Requirements:**
  - **Required Expertise:** TS full-stack (client SSE handling), server message ingestion, attachment metadata/link preview pipeline
  - **Dependencies:** None, but verify behavior across providers and any “attachment preview” middleware
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Reproduce with minimal setup and capture logs showing two LLM invocations and their triggering events.
  2. Identify where URL is being added both as text and as “attachment” (likely a UI-message conversion step + attachment provider).
  3. Add a dedupe rule: for URL-only previews, either (a) keep as text and suppress attachment, or (b) keep as attachment and strip from text—choose one consistent strategy.
  4. Add regression tests: single user message containing a URL must yield exactly one model invocation and one streamed response.
  5. Confirm no double-chunking in SSE aggregator before `done`.
- **Potential Assignees:**
  - **anchapin** (recent defensive/runtime bugfixes in core & bootstrap)
  - **odilitime** (performance + bootstrap/provider pipeline familiarity)
  - **lalalune** (runtime/message flow architecture context)

---

### 2) Embedding failures on Linux environments — elizaos-plugins/plugin-ollama #17
- **Current Status:** OPEN (community-reported; investigation started)
- **Impact Assessment:**
  - **User Impact:** Medium–High (Linux is common for self-hosting; embeddings often core to retrieval)
  - **Functional Impact:** Yes (blocks embedding-based features: RAG/memory search/vector workflows)
  - **Brand Impact:** Medium (self-hosting reliability)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Model Integration (Ollama plugin embeddings path)
  - **Complexity:** Moderate effort (environment-specific; likely binary/runtime differences)
- **Resource Requirements:**
  - **Required Expertise:** Linux debugging, Ollama API specifics, embedding request/response formats, dependency/version compatibility
  - **Dependencies:** Might depend on specific Ollama versions and how embeddings endpoints are called
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Request/collect: OS distro, kernel, Ollama version, plugin version, exact error logs, and sample embedding request payload.
  2. Add a Linux CI repro job (or docker-based integration test) that runs a minimal embeddings call.
  3. Verify whether failures are due to: endpoint mismatch, model availability, content-type/streaming differences, or CPU instruction set issues.
  4. Implement robust error messaging + fallback guidance (e.g., “pull embedding model X”, “enable endpoint Y”).
- **Potential Assignees:**
  - **mbatini** (reporter; can validate fixes)
  - **odilitime** (integration debugging)
  - A dedicated plugin maintainer for **plugin-ollama** (if designated)

---

### 3) Performance: frequent 200k token context blow-ups due to providers/evaluations baseline bloat (bootstrap providers + reflections) — ID: TBD (needs GitHub issue)
- **Current Status:** Known pain reported in Discord (active work mentioned); no single canonical tracking issue in provided data
- **Impact Assessment:**
  - **User Impact:** High (any agent with “numerous plugins” / rich provider set)
  - **Functional Impact:** Partial–Yes (can hard-fail requests due to context limits; cost spikes)
  - **Brand Impact:** High (perceived inefficiency; “framework is expensive/slow”)
- **Technical Classification:**
  - **Issue Category:** Performance
  - **Component Affected:** Plugin System (bootstrap providers), Evaluators (reflections/recent messages), Prompt assembly
  - **Complexity:** Complex solution (requires systemic prompt-budgeting + provider selection strategy)
- **Resource Requirements:**
  - **Required Expertise:** Runtime prompt construction, provider architecture, evaluation/reflection pipeline, metrics instrumentation
  - **Dependencies:** Coordinate with ongoing optimization work (e.g., action filtering / MCP loading optimizations discussed)
  - **Estimated Effort:** 4/5
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create a tracking issue in `elizaos/eliza` with a reproducible “many plugins enabled” configuration and captured token accounting per provider/evaluator.
  2. Instrument and report token contributions by provider/evaluator (top-N offenders).
  3. Implement hard budgets and truncation strategies (e.g., cap recentMessages, reflections size, provider summaries instead of raw dumps).
  4. Add a “prompt budget contract” for providers: they must return either compact summaries or structured slices, not full histories.
  5. Add regression tests that assert context stays under thresholds for a representative plugin set.
- **Potential Assignees:**
  - **odilitime** (reported issue; actively working on baseline concerns)
  - **Stan ⚡ / standujar** (has optimization interest; MCP/metatool discussion)
  - **lalalune** (runtime architecture + action filtering direction)

---

### 4) Upgrade path risk: auto-migration 1.4.x → 1.6.x removed; need explicit guardrails/error messaging before v2 upgrade — ID: TBD (derive from PR discussion around #6521)
- **Current Status:** Design decision discussed; guardrail proposed (“throw error directing users to migrate to 1.6.x first”)
- **Impact Assessment:**
  - **User Impact:** Medium (affects lagging self-hosted installs; but can be catastrophic for them)
  - **Functional Impact:** Yes (failed upgrades / broken DB schema states)
  - **Brand Impact:** Medium–High (upgrade reliability is a quality signal)
- **Technical Classification:**
  - **Issue Category:** Bug / UX (upgrade experience)
  - **Component Affected:** Core Framework (DB migrations), CLI/Upgrade docs
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** DB migration strategy, version detection, CLI messaging/docs
  - **Dependencies:** Align with ongoing DB refactor work and RLS/isolation work in v2
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a GitHub issue explicitly tracking “blocked upgrade paths” and supported version jump matrix.
  2. Add runtime/CLI preflight checks: detect schema/version; if <1.6, exit with actionable instructions (and link to migration guide).
  3. Document the supported migration sequence prominently for v2.
  4. Add a simple integration test that simulates an “old schema version” and asserts the tool fails with the correct message.
- **Potential Assignees:**
  - **standujar** (DB/RLS alignment work in PR #6521)
  - **odilitime** (parallel “great db refactor” effort mentioned)
  - **anchapin** (guardrails/defensive checks style)

---

### 5) Feature Request: Support custom OpenAI endpoint URL for OpenAI provider — elizaos/eliza #6490
- **Current Status:** OPEN (1 comment)
- **Impact Assessment:**
  - **User Impact:** Medium (users wanting OpenAI-compatible gateways like SiliconFlow)
  - **Functional Impact:** Partial (core works with official OpenAI; blocks certain deployments)
  - **Brand Impact:** Medium (perceived flexibility/extensibility)
- **Technical Classification:**
  - **Issue Category:** Feature Request
  - **Component Affected:** Model Integration (OpenAI provider), Config/CLI/env handling
  - **Complexity:** Simple fix → Moderate effort (depending on how providers are instantiated/configured)
- **Resource Requirements:**
  - **Required Expertise:** Provider config patterns, HTTP client setup, security considerations (SSRF-safe allowlisting if applicable)
  - **Dependencies:** None, but should align with how other providers accept base URLs
  - **Estimated Effort:** 2/5
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add `OPENAI_BASE_URL` (or provider-scoped config) and thread through provider initialization.
  2. Ensure compatibility with both Chat Completions and Responses APIs (whichever elizaOS uses).
  3. Add docs + examples for common OpenAI-compatible providers.
  4. Add a unit test verifying requests are routed to the configured base URL.
- **Potential Assignees:**
  - **lalalune** (core/runtime/provider architecture)
  - **odilitime** (integration pragmatics + real-world usage)
  - **coolRoger** (requester; can validate acceptance)

---

### 6) Process/Access: Discord role assignment limitations for “core dev” + labs room access requires manual steps — ID: TBD (Ops)
- **Current Status:** Workaround applied; access granted after troubleshooting
- **Impact Assessment:**
  - **User Impact:** Low (limited to a few contributors)
  - **Functional Impact:** No (but slows onboarding/coordination)
  - **Brand Impact:** Low–Medium (contributor experience)
- **Technical Classification:**
  - **Issue Category:** UX / Process
  - **Component Affected:** Community Ops (Discord permissions)
  - **Complexity:** Simple fix (permission matrix cleanup)
- **Resource Requirements:**
  - **Required Expertise:** Discord server admin, permission/role hierarchy
  - **Dependencies:** None
  - **Estimated Effort:** 1/5
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Audit role hierarchy and channel permission overrides for labs/core-dev.
  2. Document the correct onboarding flow for granting access (single checklist).
  3. Reduce reliance on manual channel additions by fixing category/channel overrides.
- **Potential Assignees:**
  - **Odilitime** (handled the incident)
  - A designated **Discord admin/mod** owner

---

## Conclusion

### (1) Top 5–10 highest priority issues to address immediately
1. **P0 — #6486 Duplicate LLM calls when messages contain URLs (webapp)**: direct cost + UX regression.
2. **P0 — Token/context blow-ups (~200k tokens) from provider/evaluator prompt bloat (TBD)**: systemic cost/failure risk for plugin-heavy agents.
3. **P1 — plugin-ollama #17 Embedding failures on Linux**: blocks retrieval/embedding workflows for common self-host setups.
4. **P1 — Upgrade path guardrails for pre-1.6 installs moving toward v2 (TBD)**: prevents broken upgrades and support load.
5. **P2 — #6490 Custom OpenAI endpoint URL**: important compatibility win; enables broader provider ecosystem.
6. **P3 — Discord role/permission friction (TBD)**: improves contributor onboarding but not product-critical.

### (2) Patterns/themes indicating deeper architectural problems
- **Prompt assembly lacks strict budgets**: providers/evaluators can over-emit content, causing runaway context size and unpredictable costs.
- **Message normalization duplication hazards**: the URL-as-text and URL-as-attachment double-processing suggests unclear ownership boundaries in the ingestion pipeline.
- **Upgrade/migration strategy in flux**: DB refactor efforts plus removed auto-migrations imply risk of fragmented upgrade experiences without explicit version gating.

### (3) Recommendations for process improvements
- **Introduce a “Prompt Budget Contract”** for providers/evaluators (max tokens, required summarization, truncation rules) and enforce it with tests/CI.
- **Add cost-and-token telemetry by default** (per provider/evaluator/action) and require attaching token breakdowns to performance-related issues.
- **Formalize upgrade support matrices** (supported version jumps) and implement CLI preflight checks to fail fast with actionable instructions.
- **Require regression tests for message ingestion edge-cases** (URLs, attachments, previews, mixed media) to prevent duplicate processing from reappearing.