fix(dreaming): use ingestion date for dayBucket instead of file date by Bartok9 · Pull Request #67091 · openclaw/openclaw

Bartok9 · 2026-04-15T08:57:09Z

Summary

When dreaming re-ingests the same daily memory file across multiple days, dailyCount stays stuck at 1 because dayBucket was set to batch.day (the file date) instead of the current ingestion date. Since dedupeByQueryPerDay checks whether todayBucket already appears in recallDays, using the file date causes every subsequent sweep to hit the dedupe guard — the file date was already recorded on the first ingestion.

This keeps signalCount (recallCount + dailyCount + groundedCount) below the default minRecallCount=3 promotion gate, so zero entries ever reach the scoring stage, and the phase reinforcement from #64068 can never take effect.

Root cause

In dreaming-phases.ts, all three ingestion functions pass the file date as dayBucket:

dayBucket: batch.day,  // e.g. "2026-04-11"

The dedupe logic in recordShortTermRecalls then checks:

const dedupeSignal =
  Boolean(params.dedupeByQueryPerDay) &&
  queryHashesBase.includes(queryHash) &&
  recallDaysBase.includes(todayBucket);

Since both queryHash and todayBucket (derived from dayBucket) are identical across sweeps, dedupeSignal is always true after the first ingestion, preventing dailyCount from incrementing.

Fix

Change dayBucket from the file date to the ingestion date (via formatMemoryDreamingDay(params.nowMs, params.timezone)) in all three call sites:

ingestSessionTranscriptSignals
ingestDailyMemorySignals
seedHistoricalDailyMemorySignals

The query string still uses the file date for identification; only the dedupe bucket changes to reflect when the sweep actually ran. formatMemoryDreamingDay was already imported and params.nowMs/params.timezone were already available at all three sites.

Test

Added a regression test that:

Ingests a daily memory file on day 1 (2026-04-05)
Clears the checkpoint, then re-ingests the same file on day 2 (2026-04-06)
Verifies dailyCount increments to 2 (was stuck at 1 before this fix)

All 22 tests in dreaming-phases.test.ts pass.

greptile-apps · 2026-04-15T08:59:24Z

Greptile Summary

Fixes a dedupe regression in the dreaming pipeline where dayBucket was set to the file's date rather than the ingestion date. Because recordShortTermRecalls uses dayBucket as todayBucket when evaluating dedupeSignal, passing the file date caused every re-ingestion sweep after the first to be treated as a same-day duplicate, keeping dailyCount permanently at 1 and blocking the promotion gate. The one-line fix at all three call sites (ingestSessionTranscriptSignals, ingestDailyMemorySignals, seedHistoricalDailyMemorySignals) is correct, and the regression test precisely covers the described scenario.

Confidence Score: 5/5

Safe to merge — targeted fix with a direct regression test and no unintended side effects.

All three changed call sites receive the same correct treatment (ingestion date instead of file date), same-day deduplication still works correctly, and the new test directly exercises the broken path. No P0/P1 issues found.

No files require special attention.

_{Reviews (1): Last reviewed commit: "fix(dreaming): use ingestion date for da..." | Re-trigger Greptile}

When dreaming re-ingests the same daily memory file on a later day, dayBucket was set to batch.day (the file date, e.g. '2026-04-11') instead of the current ingestion date. Because dedupeByQueryPerDay checks whether todayBucket already appears in recallDays, using the file date caused all subsequent sweeps to hit the dedupe guard — the file date was already in recallDays from the first ingestion. This kept dailyCount stuck at 1, signalCount below the minRecallCount=3 promotion gate, and zero entries ever reached the scoring stage. Fix: pass formatMemoryDreamingDay(params.nowMs, params.timezone) as dayBucket in all three ingestion call sites (session transcripts, daily memory, and historical seed). The query string still uses the file date for identification; only the dedupe bucket changes to reflect when the sweep actually ran. Closes openclaw#67061

jalehman · 2026-04-15T18:56:16Z

Merged via squash.

Prepared head SHA: 2df44e4d50094ba43d06ea2ba10e24ac73d56bd8
Merge commit: 4de56b18badaf7347c11ae71d2f035336fd389cc

Thanks @Bartok9!

@jalehman