FDS2610/monitor
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
monitor/api
History
fds2610-bot ad14447092 Fehlgeschlagenen Codeberg-Sync zeitnah wiederholen statt bis zum naechsten Intervall zu warten 
Auf der Produktionsmaschine traten vereinzelt Timeouts nach codeberg.org auf
("Operation timed out after 15003 milliseconds with 0 bytes received"), waehrend
die Verbindung sonst in ~0,1s antwortet.

Bisher fiel der Dauerlaeufer nach so einem Fehlschlag in den regulaeren Takt
zurueck. Weil SyncTrigger::consume() die Webhook-Anforderung schon vor dem Lauf
quittiert, war eine per Webhook angeforderte Aktualisierung damit verloren und
kam erst bis zu MONITOR_SYNC_INTERVAL Sekunden spaeter - genau die Verzoegerung,
die der Webhook abschaffen sollte.

Neu wird der naechste Versuch nach einem Fehlschlag vorgezogen: 5s, 10s, 20s, …
gedeckelt auf das regulaere Intervall (Sync\SyncSchedule). Ein kurzer Aussetzer
ist damit binnen Sekunden ueberstanden, eine laengere Codeberg-Stoerung laeuft
trotzdem nicht in einen Dauerbeschuss. Nach einem erfolgreichen Lauf gilt sofort
wieder das regulaere Intervall.

Die Wartezeit-Berechnung liegt in einer eigenen Klasse, weil die Schleife in
bin/sync-codeberg.php selbst nicht testbar ist.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-29 21:29:20 +02:00
..
bin Fehlgeschlagenen Codeberg-Sync zeitnah wiederholen statt bis zum naechsten Intervall zu warten 2026-07-29 21:29:20 +02:00
docker Phase 1 der Neuausrichtung: REST-API fuer Tickets/Events/Systeme/KPIs/Agenten 2026-07-27 19:38:52 +02:00
public Phase 1 der Neuausrichtung: REST-API fuer Tickets/Events/Systeme/KPIs/Agenten 2026-07-27 19:38:52 +02:00
src Fehlgeschlagenen Codeberg-Sync zeitnah wiederholen statt bis zum naechsten Intervall zu warten 2026-07-29 21:29:20 +02:00
tests/Unit Fehlgeschlagenen Codeberg-Sync zeitnah wiederholen statt bis zum naechsten Intervall zu warten 2026-07-29 21:29:20 +02:00
.dockerignore Phase 1 der Neuausrichtung: REST-API fuer Tickets/Events/Systeme/KPIs/Agenten 2026-07-27 19:38:52 +02:00
composer.json Phase 1 der Neuausrichtung: REST-API fuer Tickets/Events/Systeme/KPIs/Agenten 2026-07-27 19:38:52 +02:00
composer.lock composer.lock einchecken 2026-07-27 20:17:18 +02:00
phpunit.xml Phase 1 der Neuausrichtung: REST-API fuer Tickets/Events/Systeme/KPIs/Agenten 2026-07-27 19:38:52 +02:00
README.md Codeberg-Sync als Dauerlaeufer statt manuellem Aufruf 2026-07-28 23:29:40 +02:00

README.md

monitor REST-API (Phase 1)

Vanilla-PHP-REST-API (kein Framework, siehe Visualization.md Abschnitt 5) fuer Tickets, Events, Systeme, KPIs und Agenten. Persistenz in SQLite (api/data/monitor.sqlite).

Vollstaendige Endpunkt-Dokumentation: ../API.md.

Entwicklung nur mit Docker (kein lokales PHP/Composer noetig)

Aus dem Repo-Wurzelverzeichnis:

cp .env.example .env   # einmalig, MONITOR_ADMIN_API_KEY anpassen

docker compose up --build       # startet die API auf http://localhost:8080
docker compose run --rm api composer test   # PHPUnit inkl. Coverage
docker compose run --rm api php bin/sync-codeberg.php   # Backlog/Done einmalig ziehen (Debug)

Im laufenden Betrieb wird der Codeberg-Sync nicht manuell angestossen, sondern vom Compose-Service sync alle MONITOR_SYNC_INTERVAL Sekunden ausgefuehrt (siehe ../API.md, Abschnitt "Codeberg-Sync").

Composer-Abhaengigkeiten (nur PHPUnit als Dev-Dependency) werden beim ersten Start automatisch im Container installiert (docker/entrypoint.sh) - auf dem Host ist weder PHP noch Composer noch SQLite erforderlich.