Repository navigation
fix(forgetting): the bin's label decides the table a restore writes into - #192
Merged
Merged
Conversation
`purge_speaker_layer_leaks` archived an episode with `memory_type="episodes"`. `route_of` names the TABLE the row came from and expects the singular `episode`; anything it does not recognise falls through to the `core_memory` default. A restore would therefore have written an episode's summary into `core_memory`. Measured on the live bases, no row carries the wrong label, so the defect was latent — but any replay that reintroduces the leak class would have produced them. Fixed end-to-end: the episode now lands back in `episodes`. While proving that, a second and opposite error turned up. Since #191 the restore carries `created_at` when the bin recorded it, but `_CARRIED_INTO_EPISODES` is a static set, so `not_recorded` still listed `created_at` as lost for a row whose time WAS restored. That report is exactly what a caller reads to learn the limits of undo, so it was understating what came back. `_carried_into_episodes(row)` now answers per row: `created_at` joins the carried set only when `original_created_at` is present and not NULL. The check goes through `row.keys()` rather than `"col" in row` — on a `sqlite3.Row` the latter tests VALUES and silently answers False — and a bin older than the column behaves like NULL, which is what it means. Audited every `memory_type=` written in the repository: no other label routes to the wrong table. `graph:*` and `project_archive` are refused by design, the `memory_kind` values and `core_memory` all route to `core_memory`, and a missing label is refused rather than guessed. Not fixed here, reported instead: `memory_type="core_memory"` routes to the right table but `_restore_core` writes that label into `memory_kind`, which is not a valid kind — such rows are skipped by type-aware decay and invisible to kind-filtered reads. That is a separate finding with its own decision.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Что
purge_speaker_layer_leaksархивировал эпизод сmemory_type="episodes".route_ofназывает таблицу, откуда строка пришла, и ждёт единственное числоepisode; всё незнакомое падает в дефолтcore_memory. Restore положил бы summary эпизода вcore_memory."episodes"в живых базахepisodes=1, core_memory=0,created_atсохранёнВторой дефект, найденный при проверке первого
После #191 restore переносит
created_at, если в корзине естьoriginal_created_at. Но_CARRIED_INTO_EPISODES— статический набор, поэтомуnot_recordedпродолжал перечислятьcreated_atкак потерянный для строки, у которой время восстановлено.not_recorded— это ровно то, что читает вызывающий, чтобы понять границы undo. Он занижал то, что вернулось._carried_into_episodes(row)теперь отвечает по строке:created_atвходит в набор только еслиoriginal_created_atесть и неNULL. Проверка идёт черезrow.keys(), а не"col" in row— наsqlite3.Rowпоследнее смотрит значения и молча даётFalse. Бин без колонки ведёт себя какNULL, что и означает.Аудит всех меток
Прошли все
memory_type=, которые пишутся в репозитории:route_ofepisode(7 сайтов)episodescore_memory(2 сайта)core_memoryfact/question/log/goal/memory_kindcore_memoryproject_archiveNonegraph:<node_type>Nonerag/conflict.py)NoneДругих уводящих не туда нет.
Проверка
original_created_atвосстанавливается и честно сообщаетcreated_at;0.0считается записанным временем; откат каждой правки роняет свой тест.Найдено, не тронуто
memory_type="core_memory"возвращает строку в правильную таблицу, но_restore_coreкладёт эту метку вmemory_kind→memory_kind="core_memory", что не валидный kind. Следствия: type-aware decay такие строки пропускает, kind-фильтрованные выборки их не видят. Порча тихая — схема голыйTEXT. Отдельная находка со своим решением.