861cc7fc27
Il docstring di book_execute.py prescriveva «ogni ~230 minuti» mentre il cron gira ogni ora (47 * * * *). Era il docstring a sbagliare: sulla riga 4h BTC raddoppia gli scatti del disaster-SL rotolante (r0823_sl_anchor.py), e chi avesse "corretto" il cron verso il docstring avrebbe spostato il libro sulla riga peggiore. - scripts/live/book_execute.py: CADENZA: ORARIA, la riga di crontab, la ragione (giro idempotente, latenza SKH01 <=1h, ri-ancoraggio orario) e il divieto esplicito con la data. - tests/test_book_cadenza.py (10): deriva e confronta docstring, intestazione di cron_book.sh e crontab installata (crontab -l; SALTATO se illeggibile, non verde); parser a 5 campi solo per cadenze regolari; 60 < 230 < 240; minuto != :00. - docs: CLAUDE.md §5.7 chiuso, §13 conteggio 842; memoria 40; diario 02/09b. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RziUCB336YPUUyDJ29x4Ke
46 lines
2.3 KiB
Markdown
46 lines
2.3 KiB
Markdown
# 2026-09-02 — Debito 7: il docstring diceva 230 minuti, il cron gira ogni ora
|
|
|
|
*Scritto il 2026-09-02 alle 14:45Z. Cadenza misurata dal log (`r0823_sl_anchor.py`: 1.443 giri in
|
|
1.442 ore) e dalla crontab installata, letta dal test.*
|
|
|
|
## Il difetto
|
|
|
|
| fonte | cosa diceva | dal |
|
|
|---|---|---|
|
|
| `scripts/live/book_execute.py`, docstring | «va lanciato ogni ~230 minuti» | 20/06 |
|
|
| `scripts/cron_book.sh`, intestazione | cadenza ORARIA, `47 * * * *` | 25/08 (prima `:07`, sempre orario) |
|
|
| crontab della VPS | `47 * * * *` | 25/08 |
|
|
|
|
Era il **docstring** a sbagliare. E non era una svista innocua: sulla riga 4h (la più vicina ai 230
|
|
minuti) BTC **raddoppia** gli scatti del disaster-SL rotolante (2 contro 1; a 24h ETH arriva a 5, con
|
|
2 in 30 giorni). Il rischio era un lettore diligente che "allineasse" il cron al docstring.
|
|
|
|
## La riparazione
|
|
|
|
1. **Docstring riscritto**: `CADENZA: ORARIA`, la riga di crontab citata, la ragione (giro
|
|
idempotente → girare più fitto della griglia non costa ordini; latenza ≤1h sugli ingressi/uscite
|
|
software di SKH01; ri-ancoraggio orario del rotolante) e il divieto esplicito, con la data.
|
|
2. **`tests/test_book_cadenza.py`, 10 test.** P1: non ridichiara «60 minuti», **deriva** le tre
|
|
fonti e le confronta fra loro:
|
|
- il docstring non contiene più «ogni ~230» e dichiara ORARIA;
|
|
- la riga di crontab citata nel docstring è quella dichiarata in `cron_book.sh`;
|
|
- la riga dichiarata è oraria (parser a 5 campi, solo casi regolari, rifiuta il resto),
|
|
sotto i 230 della griglia e lontana dai 240 della riga peggiore, e fuori dal minuto `:00`;
|
|
- **la crontab installata** (`crontab -l`) coincide con la dichiarata. Dove la crontab non è
|
|
leggibile il test è **saltato**, non verde (P5). Sulla VPS oggi gira e passa.
|
|
|
|
## Numeri
|
|
|
|
| | |
|
|
|---|---|
|
|
| test nuovi | 10, tutti verdi; suite dei moduli che toccano `book_execute`: 231 verdi |
|
|
| cadenza dichiarata / installata | 60 min / 60 min |
|
|
| griglia SKH01 | 230 min (la riga da non usare) |
|
|
| riga peggiore misurata | 240 min (BTC 2 scatti contro 1) |
|
|
|
|
## Cosa NON ho fatto
|
|
|
|
- Non ho toccato il cron né `cron_book.sh`: la configurazione che gira era quella giusta.
|
|
- Non ho aggiunto un sorvegliante a runtime sulla cadenza (contare i giri per ora nel log): il
|
|
giornale già stampa «giri mancanti» ogni giorno, e il test copre la deriva di configurazione.
|