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

### 1) **telegram: milady wrapper + @elizaos/plugin-telegram both poll the same bot — race causes silent message loss** (#7245)
- **Current Status:** OPEN (no fix merged). Known workaround: disable one poller (plugin or wrapper).
- **Impact Assessment:**
  - **User Impact:** **High** (anyone using Telegram connector in affected app/wrapper path)
  - **Functional Impact:** **Yes** (core messaging delivery becomes unreliable; silent drops)
  - **Brand Impact:** **High** (intermittent “bot ignores me” feels like low quality and is hard to diagnose)
- **Technical Classification:**
  - **Category:** Bug / Reliability
  - **Component Affected:** Plugin System + Platform Connectors (Telegram), App runtime lifecycle
  - **Complexity:** **Moderate effort** (needs lifecycle/ownership decision + refactor/guardrails)
- **Resource Requirements:**
  - **Required Expertise:** Telegraf/Telegram long-polling semantics, connector lifecycle, app-core runtime init ordering
  - **Dependencies:** Related Telegram defects (#7240, #7241). Architectural decision: “single owner for bot token polling” (plugin vs wrapper).
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Enforce single poller per token at runtime**:
     - Add a hard guard: if wrapper starts polling, **force-disable** plugin-telegram polling (or vice versa).
     - Log a **loud warning** when a second poller is detected/configured.
  2. Add an **integration test** that asserts exactly one `getUpdates` consumer is active and that 10/10 inbound messages are processed.
  3. Decide the long-term owner:
     - Prefer **fix upstream plugin** (remove need for wrapper) once Bun/Telegraf launch is stable (#7241).
- **Potential Assignees:**
  - **Sw4pIO** (reporter; already traced root cause precisely)
  - **NubsCarson** (runtime/platform lifecycle + cross-platform stability)
  - **shawmakesmagic** (connector architecture decisions)

---

### 2) **telegram: token passing failures / setup token not applied at runtime** (#7240) *(referenced in daily engineering summary)*
- **Current Status:** OPEN (fix “Applying the Telegram setup token at runtime” in progress as **plugin-telegram PR #29**).
- **Impact Assessment:**
  - **User Impact:** **High** (blocks many first-time Telegram setups)
  - **Functional Impact:** **Yes** (connector cannot authenticate reliably)
  - **Brand Impact:** **High** (setup feels broken/out-of-box failure)
- **Technical Classification:**
  - **Category:** Bug / UX (setup)
  - **Component Affected:** Plugin-telegram, config/env bridging, runtime boot config
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** runtime config flow, env var injection, secret handling/vault integration implications
  - **Dependencies:** Coordinate with vault/secret storage behavior (recent vault work), and Telegram lifecycle fixes (#7245, #7241).
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Land PR #29 and verify on **Bun + Node** runtimes.
  2. Add a smoke test: “enter Telegram bot token in Settings → bot responds to first message within 60s.”
  3. Ensure token storage path is consistent (vault vs config.env) and does not regress headless deployments.
- **Potential Assignees:**
  - **NubsCarson** (cross-platform runtime, prior stability fixes)
  - **Dexploarer** (secrets/vault integration touchpoints)
  - **shawmakesmagic** (end-to-end product behavior validation)

---

### 3) **telegram: Bun runtime error on `bot.launch()` / Telegraf launch failure** (#7241) *(referenced in daily engineering summary)*
- **Current Status:** OPEN (currently worked around by app-level wrapper in at least one downstream).
- **Impact Assessment:**
  - **User Impact:** **Medium → High** (Bun users disproportionately affected; Telegram is a flagship connector)
  - **Functional Impact:** **Partial** (Telegram can be made to work via wrapper, but brittle)
  - **Brand Impact:** **High** (runtime instability; “works on my machine” syndrome)
- **Technical Classification:**
  - **Category:** Bug / Compatibility
  - **Component Affected:** plugin-telegram, Bun runtime compatibility
  - **Complexity:** **Complex solution** (may require upstream library workaround patterns)
- **Resource Requirements:**
  - **Required Expertise:** Bun runtime internals/quirks, Telegraf lifecycle, cross-runtime CI
  - **Dependencies:** Impacts the decision for #7245 (wrapper vs plugin ownership).
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Reproduce deterministically in CI (minimal Telegraf harness on Bun).
  2. Implement a Bun-safe launch path (e.g., avoid readonly-property mutation patterns; use polling start methods that work under Bun).
  3. Publish a temporary compatibility note and auto-detect Bun to choose safe code path.
- **Potential Assignees:**
  - **NubsCarson** (cross-platform build/runtime track record)
  - **Sw4pIO** (high-signal debugging and reproduction detail)
  - Backup: **lalalune** (if repo-structure changes touch plugin packaging)

---

### 4) **MiladyClient prototype fragmentation / multi-version client instances causing type/behavior drift** (#7233, #7244) *(referenced in daily engineering summary)*
- **Current Status:** OPEN (no merged fix indicated).
- **Impact Assessment:**
  - **User Impact:** **Medium** (likely impacts Milady/app-store users and contributors integrating clients)
  - **Functional Impact:** **Partial** (causes subtle runtime failures, inconsistent method availability)
  - **Brand Impact:** **Medium → High** (hard-to-debug “undefined is not a function” class of issues)
- **Technical Classification:**
  - **Category:** Bug / Architecture
  - **Component Affected:** Client SDK / App-core API client, packaging/bundling
  - **Complexity:** **Architectural change** (dedupe, singleton boundaries, package export discipline)
- **Resource Requirements:**
  - **Required Expertise:** TS/ESM package boundaries, bundlers (tsdown), runtime module resolution
  - **Dependencies:** Potentially coupled to repo consolidation work (PR #7235) and ESM-only core constraints.
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Identify all instantiation paths and ensure a **single canonical client package/export**.
  2. Add a runtime assertion: detect mixed prototypes/versions and fail loudly with remediation steps.
  3. Lock dependency graph to prevent dual copies (workspace constraints; pnpm/bun resolutions).
- **Potential Assignees:**
  - **NubsCarson** (app-core, cross-platform packaging)
  - **lalalune** (repo structure/workspaces)
  - **shawmakesmagic** (architecture decision-maker)

---

### 5) **Auth failures: `hasCodexCliSubscriptionAuth` expects outdated `auth.json` schema** (#7238, #7243) *(referenced in daily engineering summary)*
- **Current Status:** OPEN (no merged fix indicated).
- **Impact Assessment:**
  - **User Impact:** **High** (breaks subscription auth flows; blocks paid/entitled features)
  - **Functional Impact:** **Yes** (auth gating breaks core access paths)
  - **Brand Impact:** **High** (users perceive subscription/login as broken)
- **Technical Classification:**
  - **Category:** Bug
  - **Component Affected:** Auth subsystem, CLI integration, subscription credential storage
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** auth schema/versioning, migration patterns, backward compatibility
  - **Dependencies:** Must align with recent work on provider auth and vault/secret storage patterns.
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Implement schema versioning + migration: accept both old and new shapes, write back normalized schema.
  2. Add contract tests for `auth.json` parsing across versions (fixtures).
  3. Ensure error messages are user-actionable (where the file is, how to re-auth).
- **Potential Assignees:**
  - **NubsCarson** (auth + platform stability)
  - **Dexploarer** (secrets storage interaction / vault-first behavior)
  - **shawmakesmagic** (product-level auth expectations)

---

### 6) **Discord env var discrepancy: `voice.ts` vs `messages.ts` inconsistent environment variable handling** (Discord plugin issue #49) *(referenced in daily engineering summary)*
- **Current Status:** OPEN; standardization in progress (**plugin-discord PR #50**: standardizing `DISCORD_AUTO_REPLY`).
- **Impact Assessment:**
  - **User Impact:** **Medium** (misconfiguration/behavior mismatch for Discord bots)
  - **Functional Impact:** **Partial** (auto-reply/voice behavior diverges unpredictably)
  - **Brand Impact:** **Medium** (configuration feels inconsistent)
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component Affected:** plugin-discord
  - **Complexity:** **Simple fix → Moderate effort** (depending on deprecation/back-compat)
- **Resource Requirements:**
  - **Required Expertise:** Discord connector behavior, configuration conventions
  - **Dependencies:** Decision on “one true env var name + config mapping,” plus deprecation messaging.
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Merge PR #50 and ensure both voice + messages code paths use the same resolved config source.
  2. Add deprecation warnings for old variable names for 1–2 releases.
  3. Update docs/examples for Discord env configuration.
- **Potential Assignees:**
  - **NubsCarson** (platform consistency)
  - **odilitime** (docs/process + project coordination)
  - A Discord plugin maintainer (if designated)

---

### 7) **Large repo consolidation PR: “add cloud and plugins, remove rust and python”** (PR #7235)
- **Current Status:** OPEN (massive change; high blast radius).
- **Impact Assessment:**
  - **User Impact:** **Medium → High** (can break clones/builds/contribution workflows if mishandled)
  - **Functional Impact:** **Partial** (risk of CI/build failures; import path breakage)
  - **Brand Impact:** **Medium** (chaotic structure changes can reduce contributor confidence)
- **Technical Classification:**
  - **Category:** Maintenance / Architecture
  - **Component Affected:** Monorepo layout, CI/CD, dependency graph
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** monorepo tooling, CI pipelines, release engineering, workspace dependency constraints
  - **Dependencies:** Must not regress newly stabilized ESM-only core + plugin build compatibility work.
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P2** (do not merge until P0/P1 runtime regressions are controlled)
- **Specific Actionable Next Steps:**
  1. Require an end-to-end CI matrix: Node/Bun, Windows/macOS/Linux, packaged builds, plugin build checks.
  2. Add a migration note for contributors (new paths, removed languages, how to run tests).
  3. Gate merge behind “no open P0 Telegram regressions” to avoid compounding instability.
- **Potential Assignees (review/driver):**
  - **lalalune** (author; best positioned to adjust)
  - **NubsCarson** (CI/build + platform checks)
  - **shawmakesmagic** (final architectural approval)

---

## Immediate Focus Summary (Top Priority 5–10)
1. **P0:** #7245 — Telegram dual-polling race causing **silent message loss** (must fix; reliability + trust).
2. **P1:** #7240 — Telegram token bridging/setup token not applied at runtime (blocks setup).
3. **P1:** #7241 — Bun/Telegraf `bot.launch()` runtime failure (remove need for wrapper; stabilize plugin).
4. **P1:** #7238/#7243 — Auth schema mismatch breaking subscription auth checks.
5. **P1:** #7233/#7244 — MiladyClient prototype fragmentation causing subtle runtime errors.
6. **P2:** Discord plugin config inconsistency (#49) + merge PR #50 with back-compat and docs.
7. **P2:** PR #7235 — repo consolidation (hold until runtime stability is regained; ensure CI gates).

---

## Patterns / Themes Suggesting Deeper Architectural Problems
- **Connector lifecycle ownership is unclear** (Telegram wrapper vs plugin both starting pollers). This is a systemic lifecycle-contract gap: multiple components believe they are the “owner” of the same external integration.
- **Config/auth schema drift and silent failure modes**:
  - Auth schema expectations drifting across components (#7238/#7243).
  - Token/config bridging issues in connectors (#7240).
  - Silent “filter missing file” style failures seen recently in other areas (even when fixed, it’s a recurring pattern).
- **Packaging / module boundary fragility (ESM-only core)**:
  - Recent work removed incompatible CJS bundles across plugins, indicating ongoing sensitivity to bundling/resolution choices.
  - Prototype fragmentation issues (#7233/#7244) likely reflect multi-copy dependency resolution in complex builds.
- **Cross-runtime compatibility (Bun/Windows/headless Linux)** is a constant risk area; issues often emerge only outside the primary dev environment.

---

## Recommendations (Process Improvements)
1. **Define a “Single Owner” contract for connectors**:
   - For each platform (Telegram/Discord/etc.), specify exactly where polling/webhook lifecycle is started.
   - Add runtime guards to prevent multiple owners (fail fast + actionable logs).
2. **Add cross-runtime connector CI smoke tests**:
   - Minimal Telegram/Discord harness tests on **Bun + Node**, including “N messages in → N replies out.”
3. **Schema/versioning discipline for user state (auth/config)**:
   - Version auth/config files, provide migrations, and require contract tests with fixtures for each supported version.
4. **Replace silent fallbacks with loud diagnostics**:
   - When an expected file/env/schema is missing, log a single high-signal error that includes remediation.
5. **Pre-merge blast-radius controls for large restructuring (e.g., PR #7235)**:
   - Require a published checklist: build matrix green, plugin builds validated, docs updated, and “no open P0 runtime regressions” before merging.