fix(coding): log sanitized Pi initialization failures

This commit is contained in:
鲨鱼辣椒 committed 2026-10-14 14:50:49 +08:00
1 parent e3e26b6bd6
commit 5da90e4a06
6 files changed
+815 -7

No files matched your search

@@ -12,23 +12,31 @@
## Scope
- Diagnose the current trial Code runtime-unavailable notice using source, immutable runtime artifacts and bounded application startup diagnostics; explain what is actually known and the evidence gap.
- Continue the diagnosed Code initialization issue by adding bounded, sanitized local exception logs at the managed-worker preparation/opening boundary. Preserve existing public errors, runtime behavior and cleanup. Validate code and redaction using isolated fixtures; do not assume the original cause is fixed merely by adding logs.
## Intent And Constraints
- This request asks why; no product/source fix, app restart, user worker, paid model call, UI mutation, profile/credential/chat-history read or deployment. Isolated owned checkout based on the just-published f34e651. Read only startup diagnostics and runtime dependency metadata. Preserve current runtime and all peer/primary work.
- User now explicitly requests sanitized exception logging. Same owned Feature task/worktree/basef34 resumed through officialstart/status. Product source change is authorized; do not capture raw arbitrary error text, prompt/title, credential/env/config payload, URLs or absolute private paths. Keep only a fixed technical classification, allowlisted error name/code, safe code-frame locations and bounded correlation/fingerprint. Logger/formatter failures must not replace the product exception.
- Actual temporary app is undergoing parallel Canvas/Main network recovery and Renderer changes in other source chats. This task does not restart, inspect via private protocol, reset NetworkService or activate source files during that work. Preserve current Main/profile/project data and all peers; decide runtime delivery from a fresh coordinated source handoff rather than stale old authorization.
## Outcome
- Direct failure stage identified: the Pi Agent Server starts and reaches server.ready, then the managed session-open path fails and cleans up with open_failure. The original exception is not retained by current diagnostics, so the specific underlying cause cannot honestly be identified from existing evidence. No runtime or product changes made.
- Initial read-only diagnosis: Pi Agent Server reaches server.ready, then managed session opening fails and cleans up with open_failure. Existing logs do not retain the original exception, so they cannot prove the specific underlying cause.
- Logging continuation adds one local WARN tagged PiWorkerInitializationFailed per failed managed-worker opening. Fixed stage markers cover registry/provider/resources/credential/extension/worker startup/initial hydration/session binding; the original failure is logged before existing cleanup and never replaces public errors, rejection identity or existing cleanup propagation.
- Diagnostic output contains only allowlisted exception/code, fixed classification, bounded cryptographic text fingerprint, hashed conversation reference, worker generation and safe relative code locations when structurally available. Arbitrary error messages, function names, user content/titles, credential/env/config values, URLs and absolute private paths are not logged. Cause depth, code frames and serialized UTF-8 diagnostic size are limited to2 levels/6 frames per error/4096 bytes. A controlled realpath alias preserves official Pi package locations behind pnpm dependency links.
- Pi RPC responses currently preserve only remote error text. Fixed operation/signature projection helps recognize known remote failure patterns without copying their property/function/path suffixes; it does not claim the actual remote exception type or restore its lost stack. Native lazy stack accessors and custom formatters fail closed rather than execute formatting hooks.
- No actual application activation/restart, source publication or model/provider call in this logging continuation. Current history still does not prove the original runtime failure is fixed.
## Verification
- No tests or paid/provider invocation required for this read-only diagnosis. Source trace independently reviewed; current native-launch.log has three server.ready→open_failure cycles, no diagnostic field/original stack, and later background_sleep events do not prove recovery. Actual Main/server artifacts match active436 manifest. Pi0.84.2 files/modules/required API exports are present and resolve in the actual retained runtime; Node version meets its engine. E2E=1 is real but does not disable coding composition/Pi. No secrets/profile state read.
- Read-only diagnosis independently reviewed: native-launch.log has three server.ready→open_failure cycles, no diagnostic field/original stack; later background_sleep does not prove recovery. At that observation, actual Main/server matched436. Pi0.84.2 required modules/exports exist and resolve; Node meets its engine. E2E=1 does not disable coding composition/Pi. No secrets/profile state read.
- Final logging validation: nine relevant unit suites/119 tests passed, including19 diagnostic privacy/RPC cases,6 managed-opener failure regressions and2 isolated native-stack safety probes. Standard typecheck and scoped ESLint passed. Default full build includes Renderer/Main/preload/release utility and passed; existing Browserslist/chunk/dynamic-import notices remain unrelated. No paid/provider invocation or actual user runtime session was used.
- Independent final source review PASS. It first proved preinstalled/inherited custom formatter execution in the intermediate implementation; final data-only code and two independently rerun isolated probes now show zero formatting-hook calls, omitted lazy frames and unchanged original stack descriptors. Logger failures, original public error/rejection identity, logging before cleanup, existing cleanup-error propagation and single failure logging are covered. Official package symlink regression uses the actual canonical temp path, matching Node SDK stack behavior. Whitespace and task-aware drift checks passed.
## Follow-ups
- For a repair continuation, capture a bounded sanitized original exception at the managed session-open boundary, reproduce the failing initialization without a paid prompt, then fix its actual cause and verify the real Code session. Avoid guessing a model/network cause, blindly reinstalling dependencies or treating E2E as a disable flag. This diagnostic checkout is retained ready for that same issue; no source fix or publication was requested.
- Activate the validated logging Main artifact during the next coordinated update, then reproduce the failing initialization without a paid prompt and use new sanitized evidence to fix its actual cause. Avoid guessing a model/network cause, blindly reinstalling dependencies or treating E2E as a disable flag.
- Latest parallel Canvas handoff ea5d47787e6e43c8782ba159798bf05b93a16d27 supersedesca546 (adds Canvas-only Gallery removal; preserves yellow sidebar/no old explanation/stable create retry). The source thread also reports an actual WeChat Renderer alias atf1dabdb358ff5f2228fbef014f9e659c156ccc10 while current.json remains436. These are peer-reported delivery facts, not this task's native acceptance. A later update must freeze fresh actual sources/alias/dirty-input state and preserve WeChat changes; do not blindly overwrite using old436 metadata. This task performs no runtime actions while source coordination is incomplete.
## Promotion Candidates
@@ -46,3 +54,9 @@
- `electron/coding-runtime/pi/runtime.ts:238` managed opener includes provider projection/resources/extensions and SDK session opening;487–491 cleanup reasonopen_failure rethrows without preserving the raw error in current application logs. Existing server.ready events prove server startup/import but not successful thread/session initialization.
- Current stage native-launch.log contains E2E startup atline4; Main575 creates coding composition regardless. E2E alters startup effects/background idle timing, not a blanket Pi disable. Actual runtime/server/Main hashes match the active436 source; development resolves Pi CLI via snapshot node_modules→primary, not packaged resources/pi-runtime. Pi package/version,7server module paths and6required APIs are present. These checks do not prove every generated session/resource/configuration is valid.
- Read-only independent source and artifact reviewers agree: log evidence does not distinguish the original provider/configuration/extension/session exception. Specific diagnosis requires new sanitized exception evidence; do not call a hypothesis the proven root cause.
## Logging Resume Gate And Plan
- Same task official ownership exactly verified; startup and prior own diagnosis reloaded. Canonical positioning/decision/architecture/evidence/commitment context unchanged from previously loaded350 tree. Fresh74 and then75 peer scopes/intents/promotions independently assessed read-only; new Code gallery/old child-language placeholders remain unknown, without a concrete Pi logging dependency. Canvas is actively working Main shared networking/creation recovery, so this task performs only isolated source/test/build work. Gate Passed.
- Single-opener observation spans registry/provider/resources/credential/extension/process/initial hydration/session bind. Record original exception BEFORE cleanup inside existing catches, with a once-per-open sentinel; outer catch covers earlier failures and preserves the same rejection object and current cleanup propagation. No renderer message change or error-response expansion.
- Implement a fail-closed diagnostic formatter and focused privacy tests; wire fixed stage markers and known sensitive context in runtime.ts; add meaningful managed-opener regressions for failures before process creation, session open and cleanup/logger failure without changing public behavior. Run scoped tests/type/lint/default full build and independent review.