fix(memory-core): write meta after sync when identity is missing with existing chunks by chengzhichao-xydt · Pull Request #90395 · openclaw/openclaw

chengzhichao-xydt · 2026-06-04T15:36:26Z

Summary

Problem: Gateway memory auto-sync creates a dead loop: it indexes files (creating chunks) but never writes the memory_index_meta_v1 meta table entry when indexIdentity.status !== "valid" and !needsFullReindex. All memory_search calls return "index metadata is missing" with 0 results.
Why it matters: Users with fresh or corrupted index state cannot use memory search even though chunks exist in the database.
What changed: When the early-return path in runSync() detects identity is missing but existing chunks prevent a full reindex, the fix forces a verified full reindex via runSafeReindex/runUnsafeReindex. The reindex path prunes stale chunks from deleted paths, old providers, or old scopes before writing meta.

Design note on stale-row safety

The recovery path triggers a full reindex rather than stamping fresh metadata onto unverified chunks. The reindex path (runSafeReindex/runUnsafeReindex) scans current sources, indexes only matching files, prunes stale rows from deleted paths, and writes meta only after verification.

Guard against semantic-index downgrade: When a specific embedding provider (e.g. openai) is configured but currently unavailable, the recovery path leaves the index dirty/paused instead of forcing a reindex. Without this guard, a provider outage would cause the recovery path to silently rebuild an existing semantic/vector index as FTS-only, permanently losing vector embeddings. For auto/none/unset providers or when the provider is available, the verified full reindex proceeds safely.

Change Type

Bug fix

Scope

Memory / storage

Linked Issues

Real behavior proof

Behavior addressed: Memory index meta never written when auto-sync finds identity missing with existing chunks (#90338). Every sync cycle indexes files, creates chunks, returns early without writing meta — dead loop. The fix triggers a verified full reindex in this recovery path.

Real environment tested: Node v22.22.0, Linux x86_64, OpenClaw 2026.6.1, memory-core builtin backend with FTS-only provider.

Exact steps or command run after this patch:

Step 1 — Manager-level tests (10 FTS-only tests, 3 recovery scenarios):

OPENCLAW_VITEST_MAX_WORKERS=4 pnpm test -- extensions/memory-core/src/memory/manager.fts-only-reindex.test.ts

Step 2 — Full memory test suite (5 files, 49 tests):

OPENCLAW_VITEST_MAX_WORKERS=4 pnpm test -- extensions/memory-core/src/memory/index.test.ts extensions/memory-core/src/memory/manager.fts-only-reindex.test.ts extensions/memory-core/src/memory/manager-sync-yield.test.ts extensions/memory-core/src/memory/manager-targeted-sync.test.ts extensions/memory-core/src/memory/manager.session-reindex.test.ts

Step 3 — Live memory-search proof using MemoryIndexManager with real SQLite (console output):

$ node --import tsx/esm -e "
const {MemoryIndexManager}=await import('./extensions/memory-core/src/memory/manager.js');
// ... create manager, force sync, delete meta, verify dead loop, sync recovery, verify search
"

Evidence after fix (terminal capture — full recovery path):

=== OpenClaw Memory Recovery Proof (PR #90395) ===

--- Phase 1: Initial sync ---
  openclaw memory index --force
  Indexed: 1 files, 1 chunks
  Identity: {"status":"valid"}
  search "architecture": 1 result(s)

--- Phase 2: Create dead-loop condition ---
  Meta: MISSING, Chunks: 1
  Dead-loop condition: YES (bug!)

--- Phase 3: Search before recovery ---
  openclaw memory search "architecture"
  Identity: {"status":"missing","reason":"index metadata is missing"}
  Results: 0 (dead loop returns 0)

--- Phase 4: Recovery sync ---
  openclaw memory index
  Identity after: {"status":"valid"}
  Dirty: false, Files: 1, Chunks: 1

--- Phase 5: Search after recovery ---
  openclaw memory search "architecture"
  Results: 1
    - MEMORY.md: ...
  Dead loop broken: YES

=== Proof complete ===

Observed result after fix:

Dead loop reproduced — meta deleted, chunks remain, search returns 0 results
Recovery triggered — calling sync() without force enters the recovery path, triggers verified full reindex
Identity restored — meta is recreated with current provider/scope/chunking settings, identity becomes "valid"
Search works — memory_search returns results again, dead loop permanently broken
Stale rows pruned — chunks from deleted files are cleaned up during reindex (covered by manager tests)
Semantic guard — when a specific provider is configured but unavailable, index stays dirty/paused (covered by manager tests)

What was not tested: Live OpenClaw gateway with real embedding provider (e.g. OpenAI embeddings). The related safe-reindex race (#90453) and stale-handle fix (#90727) are tracked separately.

Co-Authored-By: Claude Opus 4.8 [email protected]

clawsweeper · 2026-06-04T15:38:55Z

Codex review: needs maintainer review before merge. Reviewed June 6, 2026, 6:14 AM ET / 10:14 UTC.

Summary
The branch changes memory-core sync so missing metadata with existing chunks triggers verified full reindex, adds a provider-unavailable guard, and adds FTS-only recovery regression tests.

PR surface: Source +21, Tests +95. Total +116 across 2 files.

Reproducibility: yes. source inspection gives a high-confidence reproduction path: current main and v2026.6.1 return dirty when metadata is missing but chunks exist, leaving search with missing identity. The PR body also supplies real SQLite terminal proof that the patched sync recovers the index.

Review metrics: 1 noteworthy metric.

Provider-state branch: 1 added. The new configured-provider-unavailable branch changes recovery behavior in a way maintainers should explicitly accept before merge.

Merge readiness
Overall: 🦞 diamond lobster
Proof: 🦞 diamond lobster
Patch quality: 🦞 diamond lobster
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Risk before merge

[P0] Specific configured embedding providers now leave missing-meta recovery dirty/paused when the provider is unavailable; that protects vector indexes but needs maintainer acceptance as the intended provider-outage behavior.
[P1] This PR should not be treated as resolving the separate safe-reindex read race or stale live-handle reports tracked at fix(memory-core): guard searches during safe reindex #90453 and fix(memory): refresh rebuilt index handles #90727.

Maintainer options:

Accept the provider pause policy
Maintainers can merge after confirming that configured-provider outages should keep missing-meta indexes dirty/paused instead of rebuilding as FTS-only.
Sequence with related memory fixes
Maintainers can land this as the missing-meta fix while reviewing the safe-reindex race and stale-handle PRs as separate memory reliability changes.
Pause for one structural memory fix
If maintainers want one combined recovery design for missing metadata, safe-reindex visibility, and stale handles, this PR should pause until that owner decision is made.

Next step before merge

[P2] The remaining action is maintainer acceptance of provider-state semantics and merge ordering, not an automated code repair.

Security
Cleared: The diff only changes memory sync logic and colocated tests; it does not add dependencies, workflow changes, secret handling, package resolution, or new code-download paths.

Review details

Best possible solution:

Land the narrow missing-meta recovery only after maintainers accept the provider-unavailable pause semantics and keep the concurrent reindex and stale-handle fixes scoped to their canonical PRs.

Do we have a high-confidence way to reproduce the issue?

Yes, source inspection gives a high-confidence reproduction path: current main and v2026.6.1 return dirty when metadata is missing but chunks exist, leaving search with missing identity. The PR body also supplies real SQLite terminal proof that the patched sync recovers the index.

Is this the best way to solve the issue?

Yes, this is the best narrow fix for the missing-meta dead loop because it reuses verified full reindex instead of writing metadata over unverified chunks. The provider-unavailable pause and related PR ordering still need maintainer acceptance before merge.

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against f4a5e5762e27.

Label changes

Label changes:

add proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix terminal proof from a real SQLite MemoryIndexManager run showing missing metadata plus chunks before recovery and successful search after recovery.
add rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🦞 diamond lobster and patch quality is 🦞 diamond lobster.
remove rating: 🐚 platinum hermit: Current PR rating is rating: 🦞 diamond lobster, so this older rating label is no longer current.

Label justifications:

P2: This is a normal-priority memory reliability fix with limited blast radius but meaningful user impact for memory search.
merge-risk: 🚨 auth-provider: The PR changes how memory recovery behaves when an embedding provider is configured but unavailable, which is provider-routing sensitive.
merge-risk: 🚨 session-state: The recovery path rebuilds and prunes the memory/session index, so a wrong policy could affect persisted memory recall state.
rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🦞 diamond lobster and patch quality is 🦞 diamond lobster.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The PR body includes after-fix terminal proof from a real SQLite MemoryIndexManager run showing missing metadata plus chunks before recovery and successful search after recovery.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix terminal proof from a real SQLite MemoryIndexManager run showing missing metadata plus chunks before recovery and successful search after recovery.

Evidence reviewed

PR surface:

Source +21, Tests +95. Total +116 across 2 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	23	2	+21
Tests	1	95	0	+95
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	2	118	2	+116

What I checked:

Current main behavior: On current main, runSync marks the index dirty and returns when index identity is invalid but existing chunks make full reindex false, which matches the reported dead-loop path. (extensions/memory-core/src/memory/manager-sync-ops.ts:1853, f4a5e5762e27)
PR implementation: The PR head makes needsFullReindex mutable and falls through to runSafeReindex/runUnsafeReindex only when metadata is missing and chunks exist, while preserving dirty/paused state when a configured provider is unavailable. (extensions/memory-core/src/memory/manager-sync-ops.ts:1871, be3db39f63bf)
Verified reindex callee: The existing full reindex paths rebuild current memory/session sources and write memory_index_meta_v1 only after the reindex work completes, so the PR uses the existing verified path rather than stamping metadata onto unverified chunks. (extensions/memory-core/src/memory/manager-sync-ops.ts:2020, f4a5e5762e27)
Provider initialization caller: The public sync path initializes the embedding provider before entering runSyncWithReadonlyRecovery, which makes the new provider-unavailable guard reviewable against existing provider lifecycle behavior. (extensions/memory-core/src/memory/manager.ts:825, f4a5e5762e27)
Regression coverage: The PR adds tests for missing-meta recovery, stale chunk pruning after deleted files, and preserving dirty/paused state when a specific provider is unavailable. (extensions/memory-core/src/memory/manager.fts-only-reindex.test.ts:209, be3db39f63bf)
Shipped behavior: Latest release v2026.6.1 still contains the early-return behavior, so this PR is not obsolete on current shipped code. (extensions/memory-core/src/memory/manager-sync-ops.ts:1796, 2e08f0f4221f)

Likely related people:

Vincent Koc: Blame on the current runSync implementation and the latest release baseline points to recent memory-core source maintenance. (role: recent area contributor; confidence: medium; commits: c72c82726f20, 2e08f0f4221f; files: extensions/memory-core/src/memory/manager-sync-ops.ts, extensions/memory-core/src/memory/manager.fts-only-reindex.test.ts)
Peter Steinberger: History shows major memory engine movement and reindex helper extraction in the central files used by this fix. (role: feature history owner; confidence: medium; commits: cad83db8b2f7, f4d8393bf4c1, c9f288ceafbf; files: extensions/memory-core/src/memory/manager-sync-ops.ts, extensions/memory-core/src/memory/manager.ts, extensions/memory-core/src/memory/manager-reindex-state.ts)
opriz: History shows the FTS-only memory search behavior that this PR extends was added in a focused prior fix. (role: adjacent behavior contributor; confidence: medium; commits: 41c30f0c5901; files: extensions/memory-core/src/memory/manager-sync-ops.ts, extensions/memory-core/src/memory/index.test.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

AyitLabs · 2026-06-04T16:50:38Z

Thanks for working on this. I reported a possibly related memory_search issue here:

#90361

I’m adding this clarification because PR #90395 looks related to the same memory-index failure cluster, but I’m not sure it addresses the specific behavior I observed in #90361.

My observed/local issue was not only “metadata missing while chunks exist.” The concerning path was:

memory_search starts;
search-triggered async sync/reindex can begin before the current search completes;
safe reindex can temporarily expose a temp DB / missing-meta state through the live manager;
the tool wrapper then checks manager.status() after search and fails closed with “index metadata is missing,” even though the durable index can be valid and later single searches return vector hits.

So from my perspective, the safer fix is probably not just “write metadata if missing but chunks exist.” That may repair one dead-loop symptom, but it seems risky if the existing chunks are stale, deleted, from a different provider/scope/chunking config, or otherwise unverified.

Expected behavior, in plain terms:

If metadata is missing and the existing chunks are not provably valid, rebuild or switch to a verified index before making search available.
If a safe reindex is in progress, live search/status should not accidentally observe a half-built temp index as if it were the durable index.
memory_search should either return valid results from a stable index or report an explicit rebuild/sync-in-progress state.

I agree with the ClawSweeper concern that stamping fresh metadata onto unverified existing chunks could make stale/out-of-scope memory searchable. I also agree deterministic race coverage would be ideal: pause safe reindex after temp DB exposure, then perform concurrent search/status reads.

I’m avoiding more stress testing on my live install for now because it is stable after a local mitigation, but I can provide screenshots/logs if the issue recurs.

One reason I think this is important: this failure can be quiet from the user’s perspective. If the agent does not explicitly surface the memory_search unavailable result, the user may only experience degraded recall and assume the agent forgot or answered weakly.

chengzhichao-xydt · 2026-06-05T03:07:01Z

Thanks for the context on #90361 — that is helpful for understanding the broader memory-index failure cluster.

This PR (#90395) is deliberately scoped to the single dead-loop path in : when identity is missing but prevents a full reindex, the sync returns early without writing meta. The fix adds the missing call in that specific early-return branch, matching the existing meta write pattern already used by / .

The race condition you described in #90361 — where a search-triggered async sync/reindex begins before the current search completes, and safe reindex temporarily exposes a temp DB / missing metadata — sounds like a separate timing/atomicity issue in the search→sync→reindex pipeline. That one would likely need a dedicated fix that coordinates the search lifecycle with the reindex lifecycle, which is outside the scope of this change.

If #90361 still reproduces after this fix lands, a follow-up PR targeting the search/reindex interleaving specifically would be the right next step.

chengzhichao-xydt · 2026-06-05T09:14:57Z

Updated PR body with real behavior proof from standalone script exercising the actual memory database code path (openMemoryDatabaseAtPath → dead-loop condition → fix → verification). The proof creates the exact dead-loop condition (chunks in FTS, meta missing), applies the fix (writeMeta), and verifies resolution (meta present, search works, idempotent). All 12 vitest sync/reindex tests pass. @clawsweeper re-review

clawsweeper · 2026-06-05T09:15:01Z

🦞👀
ClawSweeper picked this up.

Command router queued. I will update this comment with the next step.

chengzhichao-xydt · 2026-06-06T08:56:47Z

Updated the fix to trigger a verified full reindex instead of writing unverified meta. The reindex path (runSafeReindex/runUnsafeReindex) prunes stale chunks from deleted paths, old providers, or old scopes before writing meta and making the index searchable.

Changes in this push:

Recovery path now sets needsFullReindex = true instead of calling writeMeta() on unverified chunks
Removed PR-specific proof script (scripts/proof-90395-memory-meta.mjs) — proof is in PR body
Added stale-row safety test: prunes chunks from deleted paths during missing-meta recovery
All 48 memory tests pass (9 in FTS-only reindex, 39 in broader suite)

@clawsweeper re-review

clawsweeper · 2026-06-06T08:56:49Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Complete
Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
Run: https://github.com/openclaw/clawsweeper/actions/runs/27058027222
Updated: 2026-06-06T09:12:50.097Z

chengzhichao-xydt · 2026-06-06T09:28:11Z

Added semantic-index guard: when a specific embedding provider (e.g. openai) is configured but unavailable, the recovery path leaves the index dirty/paused instead of forcing an FTS-only reindex that would wipe vector embeddings.

For auto/none/unset providers or when the provider is available, the verified full reindex still proceeds.

Test coverage (10 FTS-only tests, 3 recovery scenarios):

FTS-only dead-loop recovery — reindex triggered, meta recreated
Stale chunk pruning — deleted-file chunks pruned during recovery reindex
Semantic-index guard — provider unavailable → index stays dirty, no downgrade

All 49 memory tests pass across 5 test files.

@clawsweeper re-review

clawsweeper · 2026-06-06T09:28:14Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Failed
Detail: The targeted re-review did not finish cleanly. Check the workflow run for details.
Run: https://github.com/openclaw/clawsweeper/actions/runs/27059268833
Updated: 2026-06-06T10:06:32.463Z

chengzhichao-xydt · 2026-06-06T09:51:04Z

Added live memory-search proof using MemoryIndexManager with real SQLite, demonstrating the full recovery path:

Initial sync → 1 file, 1 chunk, identity valid
Meta deleted → dead-loop condition confirmed (chunks exist, meta missing)
Search before recovery → 0 results (dead loop)
Recovery sync (no force) → triggers verified reindex
Search after recovery → 1 result, dead loop broken

The proof uses the actual memory-core module (MemoryIndexManager.get() → sync() → search()) running against a real SQLite database, equivalent to what the CLI openclaw memory index / openclaw memory search commands exercise.

All 49 memory tests pass (10 FTS-only + 39 broader suite).

@clawsweeper re-review

clawsweeper · 2026-06-06T09:51:07Z

🦞👀
ClawSweeper picked this up.

Command router queued. I will update this comment with the next step.

Re-review progress:

State: Complete
Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
Run: https://github.com/openclaw/clawsweeper/actions/runs/27059117357
Updated: 2026-06-06T09:59:34.205Z

When identity is missing but indexed chunks exist, force a verified full reindex via runSafeReindex/runUnsafeReindex instead of returning with a dirty/paused index. The reindex path prunes stale chunks from deleted paths, old providers, or old scopes before writing meta, so the index does not become searchable with unverified memory rows. Guard: when a specific embedding provider is configured but currently unavailable, the recovery path leaves the index dirty/paused instead of forcing an FTS-only reindex that would wipe existing vector embeddings. For auto/none/unset providers or when the provider is available, the verified full reindex proceeds safely. Adds three regression tests: - triggers verified reindex when identity missing + chunks exist - prunes stale chunks from deleted paths during recovery - preserves index when specific provider is unavailable Closes openclaw#90338 Co-Authored-By: Claude Opus 4.8 <[email protected]>

vincentkoc · 2026-06-11T00:53:39Z

Superseded by #91897, merged as 1a2eb74.

The landed fix keeps the missing-identity self-heal fail-closed when any semantic chunks exist, while allowing automatic recovery only when all stored chunks are explicitly fts-only. It also includes positive and negative regression coverage for that boundary.

Closing this duplicate in favor of the landed canonical implementation. The separate live-process DB inode-swap problem described in #91167 remains open and is not claimed fixed by this merge.

openclaw-barnacle Bot added extensions: memory-core Extension: memory-core size: XS triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels Jun 4, 2026

849261680 mentioned this pull request Jun 4, 2026

fix(memory-core): guard searches during safe reindex #90453

Closed

chengzhichao-xydt force-pushed the fix/90338-memory-index-meta-deadloop branch from 9fd8ef7 to 29da937 Compare June 5, 2026 02:43

chengzhichao-xydt force-pushed the fix/90338-memory-index-meta-deadloop branch from 29da937 to 17ac669 Compare June 5, 2026 02:50

chengzhichao-xydt force-pushed the fix/90338-memory-index-meta-deadloop branch from 17ac669 to 0535a64 Compare June 5, 2026 03:32

openclaw-barnacle Bot added the scripts Repository scripts label Jun 5, 2026

openclaw-barnacle Bot added size: S and removed scripts Repository scripts size: M labels Jun 6, 2026

clawsweeper Bot added merge-risk: 🚨 auth-provider 🚨 May break OAuth, tokens, provider routing, model choice, or credentials. and removed merge-risk: 🚨 security-boundary 🚨 May affect sandboxing, authorization, credentials, or sensitive data. labels Jun 6, 2026

clawsweeper Bot added rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. and removed rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. labels Jun 6, 2026

chengzhichao-xydt force-pushed the fix/90338-memory-index-meta-deadloop branch from 019865b to be3db39 Compare June 6, 2026 10:06

openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 6, 2026

This was referenced Jun 7, 2026

fix(memory-core): force full reindex when index meta is missing with existing chunks (fixes #90338) #91196

Closed

fix(memory): self-heal missing index identity during sync #91173

Closed

XueJourney mentioned this pull request Jun 10, 2026

[Bug]: memory_search stuck on index metadata is missing while gateway holds deleted SQLite backup handle #91910

Closed

vincentkoc closed this Jun 11, 2026

clawsweeper Bot mentioned this pull request Jul 13, 2026

[Bug] memory_search permanently broken for default main agent: index identity auto-vacated on every gateway restart #106239

Open

Uh oh!

Uh oh!

Conversation

chengzhichao-xydt commented Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Design note on stale-row safety

Change Type

Scope

Linked Issues

Real behavior proof

Uh oh!

clawsweeper Bot commented Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AyitLabs commented Jun 4, 2026

Uh oh!

chengzhichao-xydt commented Jun 5, 2026

Uh oh!

chengzhichao-xydt commented Jun 5, 2026

Uh oh!

clawsweeper Bot commented Jun 5, 2026

Uh oh!

chengzhichao-xydt commented Jun 6, 2026

Uh oh!

clawsweeper Bot commented Jun 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chengzhichao-xydt commented Jun 6, 2026

Uh oh!

clawsweeper Bot commented Jun 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chengzhichao-xydt commented Jun 6, 2026

Uh oh!

clawsweeper Bot commented Jun 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vincentkoc commented Jun 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

chengzhichao-xydt commented Jun 4, 2026 •

edited

Loading

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading

clawsweeper Bot commented Jun 6, 2026 •

edited

Loading

clawsweeper Bot commented Jun 6, 2026 •

edited

Loading

clawsweeper Bot commented Jun 6, 2026 •

edited

Loading