fix(scanner): Zeitplan uebersteht Neustarts

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
+4 -2
View File
@@ -52,9 +52,11 @@ SCANNER_UPLOAD_DIR=
# dieselben Projekte unabhaengig voneinander - die OpenAI-Kosten fallen doppelt an.
SCANNER_SCHEDULER=true
# Minuten Versatz fuer den ersten Lauf nach einem Neustart. Verhindert, dass
# Minuten Versatz fuer den allerersten Lauf dieser Instanz. Verhindert, dass
# beide Scanner gleichzeitig mit denselben Portal-Sessions losziehen (CAPTCHA).
# 0 = sofort loslegen. Wird ignoriert, wenn der Wert >= Suchintervall ist.
# Greift nur, solange noch kein Lauf stattgefunden hat - danach traegt der in der
# Datenbank gespeicherte Zeitpunkt (last_scan_at) den Zeitplan ueber Neustarts
# hinweg. 0 = sofort loslegen.
SCANNER_SCHEDULER_OFFSET=30
# Fallback fuer den OpenAI-Key; bevorzugt wird der Wert aus den Einstellungen.
+9
View File
@@ -97,6 +97,15 @@ export const runMatchingPipeline = async () => {
return await executePipeline();
} finally {
pipelineRunning = false;
/*
* Zeitpunkt festhalten, damit der Zeitplan einen Neustart uebersteht - sonst
* beginnt nach jedem Deployment die Wartezeit von vorn. Auch ein manueller
* Scan zaehlt: er hat die Boersen ja gerade abgefragt.
*
* Im finally, also auch nach einem Abbruch: ein gescheiterter Lauf soll sich
* nicht sofort wiederholen.
*/
await Setting.setVal('last_scan_at', new Date().toISOString()).catch(() => {});
}
};
+39 -12
View File
@@ -27,25 +27,40 @@ export const startScheduler = async () => {
}
/*
* Zeitversatz zum parallel laufenden alten Scanner. Ohne ihn starten beide
* Instanzen direkt nach einem Neustart gleichzeitig und greifen mit
* denselben Portal-Sessions zeitgleich auf die Boersen zu - das provoziert
* Rate-Limits und CAPTCHAs. Mit Versatz laufen die Laeufe verschraenkt.
* Der Zeitpunkt des letzten Laufs steht in der Datenbank (`last_scan_at`,
* geschrieben von der Pipeline). Damit ueberlebt der Zeitplan einen Neustart:
* ohne diesen Wert begann nach jedem Deployment wieder eine Sperrfrist von
* vorn - zwei Deployments im Abstand von zehn Minuten haben den faelligen
* Lauf zweimal um eine halbe Stunde verschoben, er fand also nie statt.
*/
const offsetMinutes = Number(process.env.SCANNER_SCHEDULER_OFFSET ?? 30);
const useOffset = Number.isFinite(offsetMinutes) && offsetMinutes > 0;
const storedLast = await Setting.getVal('last_scan_at', null);
const parsedLast = storedLast ? new Date(storedLast) : null;
let lastRunTime = parsedLast && !Number.isNaN(parsedLast.getTime()) ? parsedLast : null;
/*
* Eigene Sperrfrist statt eines vorgealterten lastRunTime: ein Zeitstempel
* kann einen Lauf nur vorziehen, nie verzoegern. Sobald der Versatz groesser
* als das Suchintervall ist - bei 15 Minuten Intervall der Normalfall -
* waere der erste Lauf sonst sofort faellig gewesen.
* Zeitversatz zum parallel laufenden alten Scanner - aber nur beim allerersten
* Start dieser Instanz. Danach traegt der gespeicherte Zeitstempel den
* Zeitplan, und der laeuft von sich aus versetzt zum alten Scanner weiter.
*
* Als eigene Frist umgesetzt und nicht ueber einen vorgealterten
* `lastRunTime`: ein Zeitstempel kann einen Lauf nur vorziehen, nie
* verzoegern - bei Intervall 15 und Versatz 30 waere er sofort faellig.
*/
const offsetMinutes = Number(process.env.SCANNER_SCHEDULER_OFFSET ?? 30);
const useOffset = Number.isFinite(offsetMinutes) && offsetMinutes > 0 && lastRunTime === null;
const notBefore = useOffset ? Date.now() + offsetMinutes * 60 * 1000 : 0;
let lastRunTime = null;
if (useOffset) {
console.log(`[Scheduler] Erster Lauf in ${offsetMinutes} Minuten (Versatz zum alten Scanner).`);
console.log(
`[Scheduler] Erster Lauf in ${offsetMinutes} Minuten (Versatz zum alten Scanner).`
);
} else if (lastRunTime) {
const dueAt = new Date(lastRunTime.getTime() + intervalMinutes * 60 * 1000);
const minutes = Math.max(0, Math.round((dueAt.getTime() - Date.now()) / 60000));
console.log(
`[Scheduler] Letzter Lauf ${lastRunTime.toLocaleString('de-DE')}, ` +
`naechster in ${minutes} Minuten.`
);
}
// We check every minute if we are due for a run.
@@ -88,6 +103,18 @@ export const startScheduler = async () => {
return;
}
/*
* Auch den gespeicherten Zeitpunkt beruecksichtigen: ein manueller Scan aus
* der Oberflaeche schreibt ihn, weiss aber nichts von der Variablen hier.
* Ohne diesen Abgleich koennte der Scheduler direkt hinter einem manuellen
* Lauf noch einmal losziehen.
*/
const stored = await Setting.getVal('last_scan_at', null);
const storedTime = stored ? new Date(stored).getTime() : 0;
if (Number.isFinite(storedTime) && storedTime > (lastRunTime?.getTime() ?? 0)) {
lastRunTime = new Date(storedTime);
}
// Run if never run before, or if enough time has passed
const isDue = !lastRunTime || (now - lastRunTime) >= activeIntervalMinutes * 60 * 1000;