Sascha/perinco-CRM
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(scanner): Zeitplan uebersteht Neustarts

Browse Source 
Die Sperrfrist nach dem Start begann bei jedem Neustart von vorn. Zwei
Deployments im Abstand von zehn Minuten haben den faelligen Suchlauf damit
zweimal um eine halbe Stunde verschoben - er fand nie statt. Wer oefter als
alle SCANNER_SCHEDULER_OFFSET Minuten deployt, hat einen Scanner, der
automatisch nie sucht.

Der Zeitpunkt des letzten Laufs liegt jetzt in settings.last_scan_at, von der
Pipeline geschrieben (auch nach einem Abbruch, damit sich ein gescheiterter
Lauf nicht sofort wiederholt). Der Versatz greift nur noch, solange dort nichts
steht - also beim allerersten Start dieser Instanz, wo er gebraucht wird.

Der Scheduler liest den Wert zusaetzlich in jedem Tick: ein manueller Scan aus
der Oberflaeche schreibt ihn, weiss aber nichts von der Variablen im Scheduler.
Ohne den Abgleich konnte der Scheduler direkt hinter einem manuellen Lauf noch
einmal losziehen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Sascha Wolf
2026-08-06 15:21:21 +02:00
co-authored by Claude Opus 5
parent 82d1b7eab4
commit e58b94f007
5 changed files with 83 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/03-scanner.md
+24 -7
View File
@@ -53,26 +53,43 @@ flowchart TD
A -->|nein| STOP1["nichts tun"]
A -->|ja| B{"Intervall geaendert?"}
B -->|ja| RE["neu planen"]
B -->|nein| C{"Sperrfrist nach Start<br/>SCANNER_SCHEDULER_OFFSET"}
B -->|nein| C{"Sperrfrist<br/>nur beim allerersten Start"}
C -->|noch aktiv| STOP2["nichts tun"]
C -->|abgelaufen| D{"Mo-Fr?"}
D -->|nein| STOP3["nichts tun"]
D -->|ja| E{"07:00-21:59?"}
E -->|nein| STOP4["nichts tun"]
E -->|ja| F{"Intervall seit<br/>letztem Lauf um?"}
E -->|ja| S["last_scan_at aus der DB lesen<br/>(faengt manuelle Laeufe mit ein)"]
S --> F{"Intervall seit<br/>letztem Lauf um?"}
F -->|nein| STOP5["nichts tun"]
F -->|ja| G["Pipeline starten"]
G --> W["last_scan_at schreiben"]
```
Die **Sperrfrist** ist die Antwort auf ein konkretes Problem: beide Instanzen
benutzen dieselben Portal-Cookies. Ohne Versatz ziehen nach einem Neustart beide
benutzen dieselben Portal-Cookies. Beim ersten Start ziehen sonst beide
gleichzeitig los, was Rate-Limits und CAPTCHAs provoziert - und zwei Chromium
gleichzeitig belasten den Speicher doppelt.
> Fruehere Fassung war fehlerhaft: der Versatz wurde ueber einen vorgealterten
> `lastRunTime` gebaut. Ein Zeitstempel kann einen Lauf aber nur **vorziehen**,
> nie verzoegern - bei Intervall 15 und Versatz 30 lief er deshalb sofort. Jetzt
> ist es eine eigene Frist (`notBefore`).
Der Zeitpunkt des letzten Laufs steht in `settings.last_scan_at`. Das ist kein
Luxus, sondern nach zwei beobachteten Fehlern noetig:
> **Erster Fehler:** Der Versatz war ueber einen vorgealterten `lastRunTime`
> gebaut. Ein Zeitstempel kann einen Lauf aber nur **vorziehen**, nie verzoegern -
> bei Intervall 15 und Versatz 30 lief er sofort. Seither eine eigene Frist
> (`notBefore`).
>
> **Zweiter Fehler:** Diese Frist begann bei **jedem** Neustart von vorn. Zwei
> Deployments im Abstand von zehn Minuten haben den faelligen Lauf zweimal um eine
> halbe Stunde verschoben - er fand nie statt. Wer oefter als alle 30 Minuten
> deployt, haette einen Scanner, der nie automatisch sucht. Deshalb liegt der
> Zeitpunkt jetzt in der Datenbank, und der Versatz greift nur, solange dort noch
> nichts steht.
Der gespeicherte Zeitpunkt wird auch **im Tick** gelesen: ein manueller Scan aus
der Oberflaeche schreibt ihn, weiss aber nichts von der Variablen im Scheduler.
Ohne den Abgleich koennte der Scheduler direkt hinter einem manuellen Lauf noch
einmal losziehen.
## Parallelbetrieb - alles verdoppelt