tests: kontrakt dostarczania wyniku librarian→bot (diagnoza znikających wyszukań) #11

Merged

gitea merged 1 commits from librarian-delivery-contract-tests into main 2026-08-02 15:29:34 +00:00

Conversation 0 Commits 1 Files Changed 1

+125

gitea commented 2026-08-02 14:12:13 +00:00

Owner

Copy Link

Copy Source

Po co

Diagnostyka zgłoszenia "wyszukanie znika po stronie librariana" (watchdog z PR #10 wrzuca komunikat, że wynik się "zeżarł"). Ten PR nie zmienia kodu produkcyjnego — dokłada testy komunikacji, które przybijają kontrakt strony bota i pozwalają odróżnić błąd KODU od błędu TRANSPORTU.

Co udowadniają (tests/integration/test_result_delivery_contract.py)

• transport OK → wynik dociera: kształt {uuid: {DOI: {"Title":[...], "type":...}}} przechodzi /conjurer → incoming_q → scan_incoming → IN_COMM_Q z poprawnym entries (dokładnie to, co renderuje check_data_q),
• pusty wynik {uuid: {}} też dociera (renderuje "niestety nie ma nic") — nie jest przyczyną znikania,
• zły API key → 401 → wynik znika (reprodukcja przypadku b: gdyby CONJURER_API_KEY librariana ≠ bota),
• niezgodny uuid → sierota trafia na kanał zapasowy, nie do pytającego, a rekord pytającego zostaje "wiszący" (reprodukcja przypadku b: rozjazd formatu uuid).

Wszystkie 4 zielone; pełny suite 32 integration + 48 unit.

Wniosek (kod poprawny → to transport)

Skoro kontrakt bota jest poprawny, systematyczne znikanie = librarian nie dosięga bota na CONJURER_MAIN_BOT. W deploy:

• Service bot jest type: NodePort bez przypiętego nodePort → k8s przydziela losowy z 30000–32767,
• librarian ma na sztywno CONJURER_MAIN_BOT: http://192.168.1.73:32442 — jeśli faktyczny nodePort ≠ 32442, każdy POST z wynikiem leci w zamknięty port.

Rekomendacja (deploy, robisz ręcznie): librarian jest w tym samym klastrze/namespace co bot, więc powinien gadać po DNS Service'u: CONJURER_MAIN_BOT: http://bot:5000 (bez nodePortu). Dla zewnętrznych (musician/betoniarka z Dockera) osobno przypnij nodePort: 32442 w Service bota, żeby ich twarde adresy przestały być kruche.

Jak potwierdzić na żywo: kubectl -n conjurer get svc bot -o jsonpath='{.spec.ports[0].nodePort}' (czy = 32442) oraz w logach librariana FAILED to send result / bot returned HTTP / Search <uuid> crashed.

🤖 Generated with Claude Code

## Po co Diagnostyka zgłoszenia "wyszukanie znika po stronie librariana" (watchdog z PR #10 wrzuca komunikat, że wynik się "zeżarł"). Ten PR **nie zmienia kodu produkcyjnego** — dokłada testy komunikacji, które przybijają kontrakt strony bota i pozwalają odróżnić błąd KODU od błędu TRANSPORTU. ## Co udowadniają (`tests/integration/test_result_delivery_contract.py`) - **transport OK → wynik dociera**: kształt `{uuid: {DOI: {"Title":[...], "type":...}}}` przechodzi `/conjurer → incoming_q → scan_incoming → IN_COMM_Q` z poprawnym `entries` (dokładnie to, co renderuje `check_data_q`), - **pusty wynik** `{uuid: {}}` **też dociera** (renderuje "niestety nie ma nic") — nie jest przyczyną znikania, - **zły API key → 401 → wynik znika** (reprodukcja przypadku b: gdyby `CONJURER_API_KEY` librariana ≠ bota), - **niezgodny uuid → sierota** trafia na kanał zapasowy, nie do pytającego, a rekord pytającego zostaje "wiszący" (reprodukcja przypadku b: rozjazd formatu uuid). Wszystkie 4 zielone; pełny suite **32 integration + 48 unit**. ## Wniosek (kod poprawny → to transport) Skoro kontrakt bota jest poprawny, **systematyczne** znikanie = librarian nie dosięga bota na `CONJURER_MAIN_BOT`. W deploy: - Service `bot` jest `type: NodePort` **bez przypiętego `nodePort`** → k8s przydziela losowy z 30000–32767, - librarian ma na sztywno `CONJURER_MAIN_BOT: http://192.168.1.73:32442` — jeśli faktyczny nodePort ≠ 32442, **każdy** POST z wynikiem leci w zamknięty port. **Rekomendacja (deploy, robisz ręcznie):** librarian jest w tym samym klastrze/namespace co bot, więc powinien gadać po DNS Service'u: `CONJURER_MAIN_BOT: http://bot:5000` (bez nodePortu). Dla zewnętrznych (musician/betoniarka z Dockera) osobno **przypnij** `nodePort: 32442` w Service bota, żeby ich twarde adresy przestały być kruche. **Jak potwierdzić na żywo:** `kubectl -n conjurer get svc bot -o jsonpath='{.spec.ports[0].nodePort}'` (czy = 32442) oraz w logach librariana `FAILED to send result` / `bot returned HTTP` / `Search <uuid> crashed`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

gitea self-assigned this 2026-08-02 14:12:13 +00:00

gitea added 1 commit 2026-08-02 14:12:13 +00:00

tests: pin the librarian->bot result delivery contract ... 04070ea7f1

Diagnostic coverage for the 'search vanished' report. Proves the bot side
of result delivery is correct end to end (right shape reaches IN_COMM_Q;
empty result still delivered; wrong api-key -> 401 vanish; uuid mismatch
-> orphaned away from the querent), which isolates a SYSTEMATIC vanish to
transport: the librarian being unable to reach the bot's /conjurer at all
(CONJURER_MAIN_BOT). The bot Service is NodePort with no pinned nodePort
while the librarian hardcodes :32442 - and being in-cluster it should use
the Service DNS http://bot:5000 instead.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

gitea merged commit 04070ea7f1 into main 2026-08-02 15:29:34 +00:00

gitea deleted branch librarian-delivery-contract-tests 2026-08-02 15:29:35 +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

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gitea/conjurer#11