forked from molecule-ai/molecule-core
479a027e4b
Renames: - platform/ → workspace-server/ (Go module path stays as "platform" for external dep compat — will update after plugin module republish) - workspace-template/ → workspace/ Removed (moved to separate repos or deleted): - PLAN.md — internal roadmap (move to private project board) - HANDOFF.md, AGENTS.md — one-time internal session docs - .claude/ — gitignored entirely (local agent config) - infra/cloudflare-worker/ → Molecule-AI/molecule-tenant-proxy - org-templates/molecule-dev/ → standalone template repo - .mcp-eval/ → molecule-mcp-server repo - test-results/ — ephemeral, gitignored Security scrubbing: - Cloudflare account/zone/KV IDs → placeholders - Real EC2 IPs → <EC2_IP> in all docs - CF token prefix, Neon project ID, Fly app names → redacted - Langfuse dev credentials → parameterized - Personal runner username/machine name → generic Community files: - CONTRIBUTING.md — build, test, branch conventions - CODE_OF_CONDUCT.md — Contributor Covenant 2.1 All Dockerfiles, CI workflows, docker-compose, railway.toml, render.yaml, README, CLAUDE.md updated for new directory names. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
81 lines
3.8 KiB
Markdown
81 lines
3.8 KiB
Markdown
# Known Issues
|
|
|
|
Issues identified in source but not yet filed as GitHub issues (GH_TOKEN unavailable in
|
|
automated agent contexts). Each entry has: location, symptom, impact, suggested fix.
|
|
|
|
---
|
|
|
|
## KI-001 — Telegram channel `kicked` event does not persist disabled state to DB
|
|
|
|
**File:** `workspace-server/internal/channels/telegram.go:596`
|
|
**Status:** TODO comment in source, unimplemented
|
|
**Severity:** Medium
|
|
|
|
### Symptom
|
|
When the Molecule AI bot is removed from a Telegram chat (`left` or `kicked` event), the handler
|
|
logs the event but does not update the `workspace_channels` row to mark the channel as
|
|
`enabled: false`. On the next scheduled outbound message or webhook trigger, the platform
|
|
attempts to send to a chat the bot no longer belongs to, receives a Telegram 403 error, and
|
|
logs an error — but keeps retrying on every subsequent trigger indefinitely.
|
|
|
|
### Code pointer
|
|
```go
|
|
// telegram.go:594-596
|
|
case "left", "kicked":
|
|
log.Printf("Channels: Telegram bot removed from chat %d (%s)", chat.ID, chat.Title)
|
|
// TODO: mark channel disabled in DB
|
|
```
|
|
|
|
### Suggested fix
|
|
After the `log.Printf`, call the channel manager's update method to set `enabled = false`
|
|
on the matching `workspace_channels` row (look up by `config->>'chat_id'`). Requires
|
|
injecting a DB handle or update callback into the Telegram handler — same pattern used
|
|
by `manager.go`'s `clearChatHistory` callback at line 603.
|
|
|
|
---
|
|
|
|
## KI-002 — Delegation system has no idempotency guard against duplicate execution on container-restart race
|
|
|
|
**File:** `workspace-server/internal/handlers/delegation.go` (see also `delegationRetryDelay`)
|
|
**Status:** Identified in `docs/ecosystem-watch.md` (Trigger.dev section); no fix yet
|
|
**Severity:** Medium
|
|
|
|
### Symptom
|
|
When a workspace container restarts mid-delegation (e.g. Redis TTL expires, liveness monitor
|
|
triggers restart), the `POST /workspaces/:id/delegate` call may fire again on the next agent
|
|
boot before the first delegation's result is stored. The target workspace executes the same
|
|
task twice, potentially producing duplicate side-effects (double commits, double API calls,
|
|
double Telegram messages).
|
|
|
|
### Code pointer
|
|
`delegation.go` stores delegations in the DB but uses no idempotency key. The caller
|
|
(workspace agent) has no way to detect that a delegation was already accepted; it simply
|
|
retries if the HTTP call times out.
|
|
|
|
### Suggested fix
|
|
Accept an optional `idempotency_key` field in the `POST /workspaces/:id/delegate` request
|
|
body. On receipt, check for an existing delegation row with the same `(workspace_id,
|
|
idempotency_key)` pair. If found and not failed, return the existing delegation ID (HTTP 200)
|
|
rather than creating a new row. Agents should pass `idempotency_key = sha256(task_text +
|
|
timestamp_minute)` to scope deduplication to a natural retry window.
|
|
|
|
---
|
|
|
|
## KI-003 — `commit_memory` MCP tool calls are not surfaced in `activity_logs`
|
|
|
|
**File:** `workspace/builtin_tools/memory.py` + `workspace-server/internal/handlers/activity.go`
|
|
**Status:** Identified in `docs/ecosystem-watch.md` (Letta section); no fix yet
|
|
**Severity:** Low (visibility / debugging quality)
|
|
|
|
### Symptom
|
|
When an agent calls `commit_memory`, the write succeeds and is persisted to the
|
|
`agent_memories` table, but no `activity_log` row is created. Operators inspecting the
|
|
Canvas chat "Agent Comms" tab cannot see that a memory write occurred, making it hard to
|
|
audit what an agent chose to remember during a task.
|
|
|
|
### Suggested fix
|
|
In the MCP server's `commit_memory` handler (or in the platform's `POST /workspaces/:id/memories`
|
|
handler), emit an `activity_log` entry of type `tool_call` with `method = "commit_memory"`,
|
|
`request = {key, content_length}`, and `duration_ms`. This matches the Letta pattern of
|
|
making memory operations first-class visible tool calls in the trace timeline.
|