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

## 1) Plugin initialization race condition (plugin-sql adapter registered as init() side-effect; parallel init breaks dependents) — **ID: (Discord/HackMD; needs GH issue)**
- **Current Status:** Identified in Discord + runtime refactor proposal; workaround exists in milaidy (manual pre-registration) but root cause unresolved.
- **Impact Assessment:**
  - **User Impact:** **High** (anyone using DB-backed plugins in multi-plugin setups can hit nondeterministic failures)
  - **Functional Impact:** **Yes** (can break startup / core agent runtime depending on plugin order/timing)
  - **Brand Impact:** **High** (race conditions on startup read as “unstable framework”)
- **Technical Classification:**
  - **Issue Category:** Bug / Architectural
  - **Component Affected:** Core Framework + Plugin System (runtime initialization, dependency injection)
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** Runtime architecture, TypeScript, dependency injection patterns, plugin lifecycle design, test engineering for concurrency/order
  - **Dependencies:** Align with/drive the runtime refactor proposal; may require minor API changes for plugin constructors
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Create a GitHub issue** documenting the failure mode, current workaround, and expected contract (plugins must not rely on side-effects during parallel init).
  2. Define a **deterministic initialization contract** (e.g., dependency graph + ordered phases, or explicit constructor-injected infra).
  3. Implement the minimal safe fix: **make DB adapter a required runtime/agent constructor argument** (or runtime “infra registry” built before plugin init).
  4. Add **integration tests** that run plugin init in parallel repeatedly (flaky-test harness) and verify adapter availability for dependent plugins.
  5. Deprecate “register infra in init() side-effect” pattern; publish migration guidance for plugin authors.
- **Potential Assignees:**
  - **Odilitime** (runtime refactor author/driver)
  - **s** (identified/clarified architectural nature; runtime/API sensitivity)
  - **Core runtime maintainers** familiar with plugin lifecycle

---

## 2) Active token-migration phishing/scam vectors (fake support bot, seed phrase collection) — **ID: (Security incident; needs GH issue + Discord ops ticket)**
- **Current Status:** Ongoing reports; migration is closed; moderators warning users ad hoc.
- **Impact Assessment:**
  - **User Impact:** **Critical** (risk of direct wallet compromise)
  - **Functional Impact:** **No** (not a code-path failure), but impacts user safety
  - **Brand Impact:** **High** (scams associated with project harm credibility)
- **Technical Classification:**
  - **Issue Category:** Security / UX (safety)
  - **Component Affected:** Community Ops (Discord), Documentation/Announcements, possibly website
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Discord administration/mod tooling, security comms, basic automation (bots/webhooks), incident response
  - **Dependencies:** Clear official policy: “migration closed” + canonical links
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Publish a **single canonical “Migration is closed” security notice** (pinned + locked) with “we will never ask for seed phrases” language and official links.
  2. Add **AutoMod rules** to catch common scam phrases/links (seed phrase, wallet linking, colabdesk-like domains) and auto-warn/timeout.
  3. Create an **official support workflow**: one verified support channel + bot that only points to official docs; disable/limit DMs from server bots where possible.
  4. Add a **docs page**: “How to verify official elizaOS links” + screenshot examples of common scams.
  5. Maintain an internal **incident log** (dates, domains, accounts) and share summaries weekly with moderators.
- **Potential Assignees:**
  - **Odilitime** (already responding to incidents)
  - **Odilitime + Discord moderators (e.g., Odilitime, sb, channel mods)** for policy enforcement
  - **Docs contributor (e.g., Stan ⚡)** for the public-facing page

---

## 3) plugin-ollama embeddings failing on Linux — **Issue: elizaos-plugins/plugin-ollama #17**
- **Current Status:** Open; “identified and began investigating” (per weekly summary).
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (Linux is common for self-hosting; embeddings are foundational for RAG/memory)
  - **Functional Impact:** **Partial** (core agent may run, but retrieval/memory features degrade or fail)
  - **Brand Impact:** **Medium** (plugins perceived as unreliable on common OS)
- **Technical Classification:**
  - **Issue Category:** Bug / Compatibility
  - **Component Affected:** Model Integration (Ollama plugin), Embeddings pipeline
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Linux env debugging, Ollama API behavior, embeddings model configs, Node/TS native deps if any
  - **Dependencies:** Repro steps + matrix (distros, CPU/GPU, Ollama versions); CI runner coverage on Linux
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Ensure issue has a **minimal reproducible case** (exact command, config, Ollama version, model, logs).
  2. Add **Linux CI job** to run an embeddings smoke test (or mocked contract test if Ollama can’t run in CI).
  3. Identify whether failure is due to **path/env**, **HTTP contract changes**, **model name defaults**, or **JSON schema mismatch**.
  4. Patch and release plugin version; document required Ollama versions/models for embeddings.
- **Potential Assignees:**
  - **plugin-ollama maintainers**
  - A community Linux operator willing to reproduce (recruit via Discord coders)
  - **Core model-integration contributor** if shared embeddings interface is implicated

---

## 4) Runtime refactor proposal deadline + scope control (avoid complexity spikes during 2.0 evolution) — **ID: (HackMD proposal; needs tracking issue/epic)**
- **Current Status:** Proposal shared; feedback deadline Sunday; multiple architectural concerns (plugin init, runtime setup split, infra registration).
- **Impact Assessment:**
  - **User Impact:** **High** (runtime changes affect all agents/plugins)
  - **Functional Impact:** **Partial** (current runtime works with workarounds; refactor aims to prevent systemic failures)
  - **Brand Impact:** **High** (2.0 runtime stability is central to adoption)
- **Technical Classification:**
  - **Issue Category:** Feature / Architectural / Tech Debt
  - **Component Affected:** Core Framework (Runtime), Plugin System, possibly API surfaces
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** System design, backward compatibility strategy, release engineering, migration tooling
  - **Dependencies:** Agreement on lifecycle contract; coordinated plugin updates; documentation updates
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P1** (P0 if it’s the chosen fix vehicle for the race condition above)
- **Specific Actionable Next Steps:**
  1. Convert proposal into a **GitHub epic** with milestones: (a) lifecycle spec, (b) infra registry, (c) plugin migration, (d) deprecations.
  2. Add a **compatibility plan**: what breaks in 1.x/2.x, what gets adapters/shims, and target dates.
  3. Schedule a **design review** with 2–4 maintainers; capture decisions in an ADR (architecture decision record).
  4. Implement changes behind **feature flags** if feasible to reduce risk.
- **Potential Assignees:**
  - **Odilitime** (owner/driver)
  - **s** (API complexity guardrails)
  - **Senior plugin maintainers** to validate migration impact

---

## 5) Scheduling/automation confusion across versions (plugin-cron for 2.x vs plugin-heartbeat for 1.x; adapting examples to 1.7.2) — **ID: (Discord coders thread; needs docs issue)**
- **Current Status:** Repeated questions; community shares scattered code references (Spartan examples, OpenClaw cron intervals).
- **Impact Assessment:**
  - **User Impact:** **Medium** (common need: scheduled posting/agent wake-ups)
  - **Functional Impact:** **Partial** (workarounds exist; slows implementation)
  - **Brand Impact:** **Medium** (developers perceive onboarding as fragmented)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX (developer experience)
  - **Component Affected:** Plugin System, Agent orchestration, CLI/examples
  - **Complexity:** **Simple fix → Moderate effort** (depending on whether example repo updates are needed)
- **Resource Requirements:**
  - **Required Expertise:** Docs writing, knowledge of 1.x vs 2.x scheduling plugins, example code maintenance
  - **Dependencies:** Confirm recommended path for 2.x scheduling and a supported fallback for 1.x
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Create a **“Scheduling Agents”** docs page with a version matrix:
     - 2.x: plugin-cron (examples: scheduled Discord posting)
     - 1.x: plugin-heartbeat (supported patterns + limitations)
  2. Add **copy-paste examples** (minimal agent config + one scheduled task).
  3. Link to the **Spartan** example files and clearly note version compatibility.
  4. Add a short **FAQ**: “Why doesn’t my cron wake-up fire?” (permissions, process uptime, timezone, concurrency).
- **Potential Assignees:**
  - **Odilitime** (has examples and context)
  - **AgenticCaesar** (shared cron-based ops experience)
  - **Docs contributors** (anyone active on elizaos.github.io)

---

## 6) Cloud embeddings REST endpoint design (decouple embeddings compute + storage via microservice) — **ID: (Discord discussion; needs design issue)**
- **Current Status:** Discussed conceptually; not tracked as a concrete implementation ticket in provided data.
- **Impact Assessment:**
  - **User Impact:** **Medium** (primarily cloud users / managed deployments)
  - **Functional Impact:** **Partial** (improves scalability/reliability; not required for local runs)
  - **Brand Impact:** **Medium** (cloud reliability impacts perception as platform matures)
- **Technical Classification:**
  - **Issue Category:** Feature / Performance / Architecture
  - **Component Affected:** Cloud Services, API, Embeddings pipeline
  - **Complexity:** **Complex solution**
- **Resource Requirements:**
  - **Required Expertise:** Backend/API design, vector storage, auth/rate limits, observability, deployment
  - **Dependencies:** Decision on embedding providers; storage layer contract; security model (tenant isolation)
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Write a **service contract** (endpoints, payloads, idempotency, auth, error taxonomy).
  2. Decide whether the service is **stateless compute** vs **compute+store**; define storage abstraction.
  3. Add **latency/throughput targets** and observability requirements (metrics + tracing).
  4. Prototype with one provider and one vector DB; run load tests.
- **Potential Assignees:**
  - **Odilitime** (raised architecture direction)
  - Cloud/backend contributors (Milady cloud effort participants)

---

## 7) eliza-cloud-v2 repository structure concerns (entire repo living on v2.0.0 branch vs submodules/single-source-of-truth) — **ID: (Discord question; needs tracking issue)**
- **Current Status:** Question raised; no decision captured.
- **Impact Assessment:**
  - **User Impact:** **Low–Medium** (mostly affects contributors/maintainers)
  - **Functional Impact:** **No** (unless it blocks releases or introduces drift)
  - **Brand Impact:** **Medium** (repo hygiene affects contributor confidence)
- **Technical Classification:**
  - **Issue Category:** Maintenance / Architecture / Developer Experience
  - **Component Affected:** Repo management, release process
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Git workflows, monorepo vs polyrepo strategy, release engineering
  - **Dependencies:** Team agreement on ownership boundaries; tooling constraints
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Capture the problem statement: drift, duplication, release friction, contributor confusion.
  2. Evaluate options: submodules, subtree, monorepo, or clearer branching/release conventions.
  3. Decide and document the chosen approach; add a CONTRIBUTING note.
- **Potential Assignees:**
  - **Odilitime** (infrastructure context)
  - A release-engineering-minded maintainer

---

## 8) Documentation publication for cloud-related content — **PR: elizaos/elizaos.github.io #243**
- **Current Status:** Mentioned as an action item to merge.
- **Impact Assessment:**
  - **User Impact:** **Medium** (cloud users need authoritative docs)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (docs freshness signals project maturity)
- **Technical Classification:**
  - **Issue Category:** Documentation
  - **Component Affected:** Docs site
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Docs review, basic CI familiarity
  - **Dependencies:** CI passing; ensure technical accuracy with cloud team
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Review PR for accuracy and version alignment (1.x vs 2.x vs cloud).
  2. Merge and announce in Discord with canonical links.
  3. Add follow-up issues for any missing sections discovered during review.
- **Potential Assignees:**
  - **Stan ⚡** (mentioned PR)
  - Docs maintainers + a cloud engineer reviewer

---

# Conclusion

## A) Top highest-priority issues to address immediately (next 24–72 hours)
1. **P0 — Plugin initialization race condition (plugin-sql adapter side-effect + parallel init)**: create GH issue, define deterministic init contract, implement infra injection + tests.
2. **P0 — Token-migration phishing/scam mitigation**: pinned canonical notice + AutoMod + official support workflow + link verification docs.
3. **P1 — plugin-ollama embeddings failing on Linux (#17)**: reproduce, add Linux coverage, patch + release.
4. **P1 — Runtime refactor proposal to tracked epic + decisions**: convert to epic, ADR, compatibility plan.
5. **P2 — Scheduling/automation documentation across 1.x/2.x**: publish versioned guide with minimal examples.
6. **P2 — Cloud embeddings REST endpoint design ticket**: contract + prototype plan (if cloud roadmap requires it this sprint).
7. **P2 — Merge docs PR elizaos.github.io #243**: fast review/merge to reduce support load.

## B) Patterns/themes indicating deeper architectural problems
- **Implicit side-effects and unclear lifecycle contracts** in the plugin system (infra registered during init; parallelism causing nondeterminism).
- **Version fragmentation (1.x vs 2.x)** creating repeated developer confusion (scheduling plugins, example compatibility).
- **Security incidents are recurring in community channels**, suggesting the project needs standardized, automated trust-and-safety controls rather than manual warnings.

## C) Process improvements to prevent recurrence
1. **Adopt an explicit runtime/plugin lifecycle spec** (phases, ordering, dependency declaration) and require plugins to declare required infra.
2. **Add “compatibility matrices” to docs** for common tasks (scheduling, embeddings, messaging integrations), keyed by major version.
3. **Introduce CI “ecosystem smoke tests”** (Linux plugin checks, plugin init ordering tests, minimal agent boot with representative plugin sets).
4. **Create a lightweight security operations playbook**: pinned canonical links, AutoMod rules, incident log, and templated announcements for scams.
5. **Convert major Discord design discussions into GH artifacts within 24 hours** (issue/epic + ADR) to avoid losing decisions and to improve contributor coordination.