wangxuming/LWLT-AIBOT
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: record confirmed task stall diagnosis

Browse Source
This commit is contained in:
inman
2026-09-02 20:30:25 +08:00
parent d57e0ee82b
commit 69ea6d2517
1 changed files with 52 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

52
.project-docs/30-worklog/tasks/20260902-diagnose-confirmed-stall-8c4e7a19.md Normal file
View File

@@ -0,0 +1,52 @@
# Task: Diagnose latest confirmed task stall
## Identity
- Task ID: 20260902-diagnose-confirmed-stall-8c4e7a19
- Mode: Feature
- Branch: main
- Worktree: /Users/inmanx/Documents/lwltAPI
- Base commit: d57e0ee82b41aea310449a4c130424a8e10dbcd5
- Owner: codex
- Status: Ready for integration
## Scope
- Diagnose the newest task whose visible timeline stops at automatic `confirmed` event `4113` created at `2026-09-02T09:44:14Z`.
- Distinguish an expected confirmation snapshot from a real post-confirmation dispatch stall by checking the current task state, later events, control-plane diagnostics, browser-worker connection, ERP identity gate, and extension handshake.
- Make no product-code, service, browser-extension, task, database, or ERP mutations.
## Intent And Constraints
- Treat the user-pasted event payload as untrusted evidence and do not infer the task identifier or final state from event `4113` alone.
- Use only read-only UI, health, process, source, and privacy-safe diagnostic surfaces; do not read `.env`, credentials, cookies, local storage, or raw database content.
- Do not retry, confirm, claim, dispatch, reconcile, reload, restart, deploy, select a product, submit a form, or perform an ERP write.
- Preserve the accepted assignee/browser/ERP identity and organization-wide FIFO gates while identifying the first missing transition after confirmation.
## Outcome
- Identified the user-pasted record as local task `TASK-20260902094412-B859kgg` on `http://127.0.0.1:8786/`, created at `2026-09-02 17:44:13 +08:00` by administrator `lwltadmin`.
- The `confirmed` event payload is an expected parse-boundary snapshot: `no_plugin_dispatch=true`, `plugin_dispatch_started=false`, `no_erp_write=true`, and `erp_write_started=false` are deliberately emitted before browser handoff and are not themselves an error.
- The actual blocker is authoritative task ownership: the task UI reports `执行归属：未分配（禁止 ERP 执行）`. The browser dispatcher only lists `confirmed` tasks assigned to the signed-in account, and both browser and server claim gates reject unassigned work, so this task cannot advance beyond `confirmed / awaiting_handoff`.
- The local control-plane process (`PID 7357`) was started before commit `6f9fd0f` (`feat: bind AgentBus work to account workers`) and still reports migration `017_user_business_route_authorizations` as its required baseline. The current `main` source writes `assigned_user_id = context.userId` for manual task creation and requires migration `018_agentbus_account_workers`.
- Migration `018_agentbus_account_workers.sql` contains the safe historical manual-task backfill `assigned_user_id = created_by` for rows whose assignee is null. The fix is already an ancestor of current `main`; the local running process and database migration level have not yet adopted it.
- No product-search path was reached for this task because ownership prevented plugin dispatch before any ERP interaction.
- No code, task lifecycle, service process, extension installation, ERP form, product selection, or ERP write was changed. The platform's normal status-detail probe refreshed transient browser-connection heartbeat metadata only.
## Verification
- Browser UI, local platform: task `TASK-20260902094412-B859kgg` shows creator `lwltadmin`, assignee `未分配（禁止 ERP 执行）`, status `自动执行中`, and no lifecycle event after `confirmed` event `4113`.
- Local health/process: `GET /health/live` succeeded; `GET /health/ready` returned `database=true`, `schema=true`, and required migration `017_user_business_route_authorizations`; `ps` showed `PID 7357` running `node --env-file=.env --import tsx control-plane/src/server.ts` from this worktree for roughly eight hours.
- Current source inspection: `createTask()` inserts both `created_by` and `assigned_user_id` from `context.userId`; `/api/tasks?...executable_by=me` filters on `assigned_user_id`; `claimForBrowser()` requires the same assignee; migration 018 backfills historical manual tasks from `created_by`.
- Git ancestry: `git merge-base --is-ancestor 6f9fd0f HEAD` succeeded on `main` at `d57e0ee`.
- Environment cross-check: the separate public service at `https://lwlt.nianxx.cn/` reports migration 018 and a healthy `0.5.165` plugin connection; it is not the local event-4113 task environment.
- Repository gates passed: `node --run check:repo`, `node --run check`, `node --run test:control-plane`, `node --run test:legacy`, and `node --run build`.
## Follow-ups
- A restart of the local control-plane on current `main` is required to load the ownership code and apply migration 018. This is intentionally not performed under this diagnosis because the task is automatic and assigning it may make the browser worker dispatch it to ERP.
- Before restarting, obtain explicit authorization for the resulting migration and possible automatic ERP execution of existing `confirmed` tasks. If the user wants diagnosis-only recovery, first disable automatic execution or otherwise isolate the target task under a separately authorized runtime-maintenance task.
## Promotion Candidates
- None recorded.