Summary

Re-running wiki_apply create_synthesis for an existing synthesis page, or re-running the ChatGPT conversations import over already-imported pages, silently wipes the user's hand-written ## Notes block and drops hand-added frontmatter when the existing-page read fails transiently (EBUSY/EMFILE/ENFILE style faults). The page is treated as brand-new and the regenerated content replaces the user's edits without any error surfacing.

PR #98360 fixed this defect class for ingest.ts and source-page-shared.ts (issue #98345) but did not cover these two surfaces.

Root cause

Both surfaces swallow every existing-page read error and continue with an empty page.

Before, extensions/memory-wiki/src/apply.ts:231 in applyCreateSynthesisMutation:

const existing = await root.readText(pagePath).catch(() => "");

Before, extensions/memory-wiki/src/chatgpt-import.ts:762 in importChatGptConversations:

const existing = await fs.readFile(absolutePath, "utf8").catch(() => "");

With an empty existing, applyCreateSynthesisMutation keeps none of the frontmatter that only lived on disk (for example a hand-added privacyTier) and buildSynthesisBody regenerates an empty ## Notes scaffold, which writeWikiPage then persists. In the importer, preserveExistingPageBlocks receives an empty existing, so the human notes and ## Related blocks are not carried over, the write is misclassified as create instead of update or skip, and the rollback record snapshots an empty existing for that page.

Fix

Route both reads through a local retry-once helper that treats only a genuinely missing page as new and propagates a failure that persists across the retry, the same shape #98360 shipped for ingest and imported-source pages. Unlike those two call sites, these reads have no existence gate (a missing page is the normal create path), so the helpers translate missing-page errors to an empty string instead of rethrowing them.

After, extensions/memory-wiki/src/apply.ts:

async function readExistingWikiPage(root: VaultRoot, pagePath: string): Promise<string> {
  try {
    return await root.readText(pagePath);
  } catch (error) {
    if (isMissingWikiPageError(error)) {
      return "";
    }
    try {
      return await root.readText(pagePath);
    } catch (retryError) {
      if (isMissingWikiPageError(retryError)) {
        return "";
      }
      throw retryError;
    }
  }
}

isMissingWikiPageError matches FsSafeError codes not-found and path-alias, the same missing-page classification okf.ts already uses for vault stat calls. chatgpt-import.ts gets the equivalent readExistingConversationPage keyed to plain fs ENOENT.

writeWikiPage's change-detection read at apply.ts:207 is routed through the same helper so the file has one canonical existing-page read; a transient failure there previously caused only a spurious identical rewrite, never data loss.

Why this is the right boundary

• apply.ts owns the synthesis page lifecycle and chatgpt-import.ts owns imported conversation pages, so each gets the same local helper pattern fix(memory-wiki): preserve notes after transient page reads #98360 established in ingest.ts and source-page-shared.ts, keyed to its own missing-page error shape (FsSafeError for the vault root, ENOENT for plain fs).
• These were the last two paths that merge preserved human content into a rewrite from a swallowed existing-page read. The remaining .catch(() => "") reads in the plugin are not user-content-lossy: okf.ts:461 and compile.ts:1377 use the read only for change detection before writing fully caller-computed content, and okf.ts:496 fails safe by skipping removal.
• compile.ts writeManagedMarkdownFile and writeDashboardPage fall back to a fresh scaffold for plugin-generated index/dashboard/report pages; a transient read failure there can reset plugin-generated scaffolding but does not touch user-authored notes pages. Flagging as a candidate follow-up if the same retry treatment is wanted there.
• Fail-closed on persistent read errors matches the direction fix(memory-wiki): preserve notes after transient page reads #98360 shipped: the mutation or import errors out and can be retried instead of silently destroying user edits.

Verification

• node scripts/run-vitest.mjs extensions/memory-wiki/src/wiki-notes-read-retry.test.ts extensions/memory-wiki/src/apply.test.ts extensions/memory-wiki/src/import-runs.test.ts: 3 files, 13 tests passed with the patch.
• The two new regression tests fail on pristine main 17482a4 (notes and frontmatter wiped) and pass with the patch; the two pre-existing fix(memory-wiki): preserve notes after transient page reads #98360 tests in the same suite stay green.
• node scripts/run-oxlint.mjs on the three changed files: clean.
• oxfmt --check on the three changed files: clean.
• node scripts/run-tsgo.mjs -p tsconfig.extensions.json and -p test/tsconfig/tsconfig.extensions.test.json: clean.

Real behavior proof

Behavior addressed: a single transient read failure of the existing page during a create_synthesis re-run or a ChatGPT re-import silently empties the user's ## Notes block, drops hand-added frontmatter, and misclassifies the import operation.
Real environment tested: drove applyMemoryWikiMutation (the production wiki_apply mutation entry point) and importChatGptConversations (the production ChatGPT import entry point) against a real on-disk vault, on pristine main 17482a4 and on the patched tree with identical inputs; vault initialization, markdown render/parse, compile, and all page writes were the real runtime on disk; the one injected fault was a single EBUSY error on the existing-page read.
Exact steps or command run after this patch: create the synthesis page via applyMemoryWikiMutation create_synthesis "Release Plan", hand-edit its notes block and add privacyTier frontmatter on disk, re-run the same mutation with one EBUSY injected on the syntheses/release-plan.md read; separately import a ChatGPT export via importChatGptConversations, hand-edit the conversation page notes, re-run the identical import with one EBUSY injected on that page read; then print the resulting page files.
Evidence after fix:

# BEFORE (pristine main 17482a4026)
$ wiki_apply create_synthesis 'Release Plan' (re-run with one EBUSY on the existing-page read)
syntheses/release-plan.md frontmatter privacyTier line: MISSING (hand-added frontmatter dropped)
syntheses/release-plan.md notes section:
## Notes
<!-- openclaw:human:start -->
<!-- openclaw:human:end -->

$ openclaw wiki chatgpt-import (re-run of same export with one EBUSY on the existing-page read)
import result: created=1 updated=0 skipped=0
chatgpt-2024-04-06-123456781234123412341234567890ab.md notes section:
## Notes
<!-- openclaw:human:start -->
<!-- openclaw:human:end -->

# AFTER (this patch, identical inputs)
$ wiki_apply create_synthesis 'Release Plan' (re-run with one EBUSY on the existing-page read)
syntheses/release-plan.md frontmatter privacyTier line: privacyTier: sensitive
syntheses/release-plan.md notes section:
## Notes
<!-- openclaw:human:start -->
Ship gate: legal sign-off required before GA.
<!-- openclaw:human:end -->

$ openclaw wiki chatgpt-import (re-run of same export with one EBUSY on the existing-page read)
import result: created=0 updated=0 skipped=1
chatgpt-2024-04-06-123456781234123412341234567890ab.md notes section:
## Notes
<!-- openclaw:human:start -->
HUMAN NOTE: verified against the airline booking.
<!-- openclaw:human:end -->

Observed result after fix: after one transient EBUSY on the existing-page read, the re-synthesized page keeps the user's notes line and hand-added privacyTier frontmatter, and the re-imported conversation page keeps its notes and is classified skipped instead of being recreated with an empty notes block.
What was not tested: no live gateway session drove wiki_apply over RPC; the EBUSY fault was injected at the read seam rather than produced by a real file lock; full build not run on this machine.

Related

• memory-wiki: transient existing-page read failure during re-ingest silently wipes the user ## Notes block #98345 reported this class for re-ingest; fix(memory-wiki): preserve notes after transient page reads #98360 fixed ingest.ts and source-page-shared.ts only.
• memory-wiki unsafe-local sync deletes imported pages and user human-notes blocks when a configured source path is transiently unavailable #97523 covers the unsafe-local sync prune path and is unrelated to these read sites.
• Closed PRs fix(memory-wiki): retry transient existing-page read failures before writing (#98345) #98364, fix(memory-wiki): propagate read errors instead of silently wiping human notes #98367, fix(memory-wiki): retry transient existing-page reads to preserve human Notes blocks #98555 all targeted the same two files as fix(memory-wiki): preserve notes after transient page reads #98360 and do not touch apply.ts or chatgpt-import.ts.