Meleki
b645625b56
Cronjobs: - CronjobService (BackgroundService) prüft jede Minute auf fällige Jobs - Cron-Expression in Server-Lokalzeit via Cronos (CronFormat.Standard) - Cronjob-Ausführung: Prompt → Session → Agent-Antwort in Chat-History - Optionale Benachrichtigungs-Session (notify_session_id): Zusammenfassung wird in separate Session geschrieben (z.B. mit Telegram) - Telegram-Benachrichtigung mit Cronjob-Name + Ursprungs-Session - REST API: CRUD + toggle + manuelles Ausführen (/run) - Frontend: Dashboard-Cards, Cronjob-Formular mit Cron-Vorschau, Session-Dropdown, Notify-Session-Dropdown, Status-Box Refactoring: - AnthropicService als Singleton in DI registriert - ChatEndpoint + TelegramService nutzen injizierte Instanz - Redundante Dependencies (Token, ToolService, MemoryService) entfernt Neue Dateien: - Models/CronjobRecord.cs - Services/CronjobService.cs - Endpoints/CronjobEndpoint.cs - wwwroot/js/pages/cronjob-page.js - PLAN-Cronjob.md
74 lines
3.4 KiB
Markdown
74 lines
3.4 KiB
Markdown
## Cronjobs – Planungsentwurf
|
||
|
||
### Konzept: Eigener Worker/Service in der App
|
||
|
||
**Warum nicht Linux-Cron?**
|
||
- App ist self-contained, soll ohne externe Abhängigkeiten laufen
|
||
- Cronjobs brauchen Zugriff auf DB, Agents, Sessions, Anthropic API
|
||
- Verwaltung über das Frontend (Dashboard) wäre mit Linux-Cron extrem umständlich
|
||
- Multi-User: Jeder User hat eigene Cronjobs
|
||
|
||
### Architektur
|
||
|
||
**Backend:**
|
||
|
||
1. **`CronjobRecord`** (Model) – DB-Tabelle `cronjobs`:
|
||
- `cronjob_id` (TEXT, GUID)
|
||
- `user_id` (TEXT)
|
||
- `session_id` (TEXT) – in welcher Session soll der Prompt gesendet werden
|
||
- `name` (TEXT) – z.B. "Täglicher Standup-Report"
|
||
- `cron_expression` (TEXT) – Standard Cron-Format: `0 9 * * *` (jeden Tag um 9:00)
|
||
- `prompt` (TEXT) – die Nachricht die an Claude gesendet wird
|
||
- `is_enabled` (BOOL) – aktiv/inaktiv
|
||
- `last_run_at` (TEXT) – wann zuletzt ausgeführt
|
||
- `next_run_at` (TEXT) – nächste geplante Ausführung (vorberechnet)
|
||
- `last_run_status` (TEXT) – "success" / "error"
|
||
- `last_run_error` (TEXT) – Fehlermeldung falls error
|
||
- `created_at`, `updated_at`
|
||
|
||
2. **`CronjobService`** (IHostedService / BackgroundService):
|
||
- Startet mit der App als `AddHostedService<CronjobService>()`
|
||
- Timer prüft jede Minute: "Gibt es Cronjobs deren `next_run_at` <= jetzt?"
|
||
- Wenn ja: Prompt an die Session senden (wie ein normaler Chat-Request, aber ohne SSE – fire & forget, Result in DB speichern)
|
||
- Nach Ausführung: `last_run_at` updaten, `next_run_at` neu berechnen
|
||
|
||
3. **`CronjobEndpoint`** (REST API):
|
||
- `GET /api/cronjobs` – alle Cronjobs des Users
|
||
- `POST /api/cronjobs` – neuen Cronjob anlegen
|
||
- `PUT /api/cronjobs/{id}` – bearbeiten
|
||
- `DELETE /api/cronjobs/{id}` – löschen
|
||
- `POST /api/cronjobs/{id}/toggle` – aktivieren/deaktivieren
|
||
- `POST /api/cronjobs/{id}/run` – manuell sofort ausführen (zum Testen)
|
||
|
||
4. **Cron-Expression Parser**: Nutzen wir `Cronos` NuGet-Package (leichtgewichtig, kein Overhead) oder schreiben wir einen eigenen einfachen Parser?
|
||
|
||
**Frontend:**
|
||
|
||
5. **Dashboard**: Neue Section "Cronjobs" mit Cards (ähnlich Sessions/Agents)
|
||
6. **Cronjob-Formular** (neue Page `tpl-cronjob`):
|
||
- Name
|
||
- Session (Dropdown)
|
||
- Cron-Expression (Input + Vorschau "Nächste Ausführung: ...")
|
||
- Prompt (Textarea)
|
||
- Aktiv/Inaktiv Toggle
|
||
7. **Cronjob-Card**: Name, Session-Name, Cron-Expression human-readable, Status (aktiv/inaktiv), letzte Ausführung
|
||
|
||
### Offene Fragen an dich:
|
||
|
||
1. **Cron-Expression oder vereinfacht?** Soll der User echte Cron-Expressions eingeben (`0 9 * * 1-5`) oder lieber ein vereinfachtes UI (Dropdown: "Täglich um X", "Wöchentlich am Y um Z", etc.)?
|
||
|
||
2. **Ausführung**: Soll der Cronjob die Antwort von Claude still in die Session-History schreiben (so als hätte der User die Nachricht geschrieben)? Oder soll es einen separaten "Cronjob-Log" geben?
|
||
|
||
3. **NuGet `Cronos`** für Cron-Parsing verwenden? (Ist der De-facto-Standard in .NET, ~50KB, keine Abhängigkeiten)
|
||
|
||
4. **Benachrichtigung**: Soll der User benachrichtigt werden wenn ein Cronjob ausgeführt wurde? (z.B. über die StatusBar, oder Telegram?)
|
||
|
||
--
|
||
|
||
Antworten auf die offenen Fragen:
|
||
|
||
1. Cron-Expression
|
||
2. Einfach direkt in die Session-History schreiben (als hätte der User die Nachricht geschrieben)
|
||
3. Cronos NuGet passt
|
||
4. Telegram, falls in der Session, in der der Cronjob läuft, Telegram eingerichtet und verbunden ist
|