gitea/conjurer
1
0
Fork 0
Code Issues Pull Requests 1 Actions 1 Packages Projects Releases Wiki Activity

librarian: sygnał życia trwającego wyszukiwania (co 20 min) #21

Merged
gitea merged 1 commits from librarian-search-heartbeat into main 2026-08-04 10:38:19 +00:00
Conversation 0 Commits 1 Files Changed 3
+179 -5
gitea commented 2026-08-04 10:10:07 +00:00
Owner
Copy Link
Copy Source

Po co

Głęboki skan mieli godzinami i w logu jest cisza między startem a końcem — nie odróżnisz pracującego wyszukiwania od zawieszonego.

Co loguje

Co CONJURER_LIBRARIAN_HEARTBEAT_SECONDS (domyślnie 1200 = 20 min), tylko gdy coś faktycznie leci:

SEARCH ALIVE 6f2c… | 'kwas foliowy' | ~37.4% przeskanowane (12.31/32.90 GB, ~20.59 GB do końca) | 18 trafień | 94 min

uuid, szukane hasło, orientacyjny postęp, ile trafień do tej pory, ile minut leci. Nic nie leci → cisza.

Dlaczego to nic nie kosztuje

Producenci już zapisują offset bajtowy per plik-chunk (to te same watermarki, których używa wznawianie), a suma rozmiarów plików jest liczona raz przy odkryciu chunków (~40 × stat()). Odczyt postępu = suma ~40 intów. Zero dodatkowej pracy na linię — żadnych cykli na szacowanie, ile cykli zostało.

Jak wpięte

search_for_doi przyjmuje opcjonalny progress, który wypełnia żywym dictem positions + total_bytes. Librarian publikuje trwające wyszukanie (uuid/query/progress/trafienia) na czas skanu i czyści je w finally — więc skończony/scrashowany skan nigdy tam nie zostaje.

Testy

Matematyka procentów (w tym nieznany total i klamrowanie >100%), round-trip rejestracji, oraz end-to-end: realny skan wypełnia progress tak, że offsety pokrywają pliki na dysku. Suite: 58 unit + 65 integration zielone.

🤖 Generated with Claude Code

## Po co Głęboki skan mieli godzinami i **w logu jest cisza** między startem a końcem — nie odróżnisz pracującego wyszukiwania od zawieszonego. ## Co loguje Co `CONJURER_LIBRARIAN_HEARTBEAT_SECONDS` (domyślnie **1200 = 20 min**), tylko gdy coś faktycznie leci: ``` SEARCH ALIVE 6f2c… | 'kwas foliowy' | ~37.4% przeskanowane (12.31/32.90 GB, ~20.59 GB do końca) | 18 trafień | 94 min ``` uuid, szukane hasło, orientacyjny postęp, ile trafień do tej pory, ile minut leci. Nic nie leci → **cisza**. ## Dlaczego to nic nie kosztuje Producenci **już** zapisują offset bajtowy per plik-chunk (to te same watermarki, których używa wznawianie), a suma rozmiarów plików jest liczona **raz** przy odkryciu chunków (~40 × `stat()`). Odczyt postępu = suma ~40 intów. **Zero dodatkowej pracy na linię** — żadnych cykli na szacowanie, ile cykli zostało. ## Jak wpięte `search_for_doi` przyjmuje opcjonalny `progress`, który wypełnia **żywym** dictem `positions` + `total_bytes`. Librarian publikuje trwające wyszukanie (uuid/query/progress/trafienia) na czas skanu i czyści je w `finally` — więc skończony/scrashowany skan nigdy tam nie zostaje. ## Testy Matematyka procentów (w tym nieznany total i klamrowanie >100%), round-trip rejestracji, oraz **end-to-end**: realny skan wypełnia `progress` tak, że offsety pokrywają pliki na dysku. Suite: **58 unit + 65 integration** zielone. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
gitea self-assigned this 2026-08-04 10:10:07 +00:00
gitea added 1 commit 2026-08-04 10:10:08 +00:00
Librarian: 'still searching' heartbeat every 20 min
CI / compile (pull_request) Successful in 18s
Details
CI / unit (pull_request) Successful in 39s
Details
CI / integration (pull_request) Failing after 1m2s
Details
CI / compile (push) Successful in 14s
Details
CI / unit (push) Successful in 34s
Details
CI / integration (push) Successful in 37s
Details
build / build (push) Successful in 33s
Details
9f22dbf94b 
A deep scan runs for hours with nothing in the log between start and
finish, so it's impossible to tell a working search from a wedged one.
Every CONJURER_LIBRARIAN_HEARTBEAT_SECONDS (default 1200 = 20 min) a
running search now logs that it is still going, with its uuid, the search
phrase, hits so far, elapsed minutes, and a rough how-far-along.

The estimate is deliberately cheap: the producers ALREADY record a byte
offset per chunk file (the resume watermarks), and the total size is
stat()'d once per search when the chunk list is discovered. A reading is
then just a sum over ~40 ints - nothing extra happens per line, and no
cycles are spent estimating how many cycles are left.

search_for_doi takes an optional progress dict it fills with the live
positions dict + total_bytes; the librarian publishes the running search
(uuid/query/progress/live hits) while the scan runs and clears it in
finally. Nothing running => the heartbeat stays quiet.

Tests: percentage maths incl. unknown-total and >100% clamping, the
register/clear round-trip, and an end-to-end check that a real scan fills
progress so the offsets cover the chunk files on disk. Suite: 58 unit +
65 integration green.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
gitea merged commit 9f22dbf94b into main 2026-08-04 10:38:19 +00:00
gitea deleted branch librarian-search-heartbeat 2026-08-04 10:38:20 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
gitea
No Assignees gitea
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: gitea/conjurer#21
Delete Branch "librarian-search-heartbeat"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?