Aquesta és una versió anterior. La versió actual és la 2.2.20. LobeHub 2.2.20 · Data de publicació:
Fitxers d’instal·lació 2.1.52
| Arquitectura | Tipus | Àmbit | Mida del fitxer | Baixa | SHA256 |
|---|---|---|---|---|---|
| 64 bits | EXE (NSIS) | Usuari actual | — | github.com | VirusTotal |
| 64 bits | EXE (NSIS) | Tots els usuaris | — | github.com | VirusTotal |
L’enllaç i l’SHA256 provenen del manifest comunitari del Gestor de paquets del Windows. Convé comparar el hash del fitxer baixat abans d’executar-lo.
Notes de la versió
This release was automatically published from PR #13994.
Changes
See PR description: https://github.com/lobehub/lobehub/pull/13994
Commit Message
This release ships a database schema migration that makes two pieces of lifecycle state explicit: how a topic finishes, and how a task is automated. Both already existed implicitly, which made some downstream behaviors ambiguous. This change turns them into first-class columns so the UI, scheduler, and reporting layers can rely on them directly.
Migration overview
Previously, a topic's completion was inferred from surrounding context — there was no dedicated status or timestamp marking when a topic moved out of the active pool. Tasks had a similar ambiguity around automation: heartbeat supervision and cron-style scheduling lived in overlapping fields, so a configured-but-paused schedule looked identical to one that was never set.
This migration makes both states explicit.
topics
- status (active | completed | archived)
- completed_at timestamp
- Indexes on status and (user_id, completed_at) so completion views and archival queries stay cheap
tasks
- automation_mode (heartbeat | schedule | null) — a single discriminator that makes the two automation kinds mutually exclusive by design and removes the "configured but disabled" ambiguity
- Index on automation_mode
In practice, the topic list can now distinguish completed and archived records without reinterpreting other fields, and the task scheduler gets a clean switch to route records between heartbeat supervision and cron execution.
Notes for self-hosted users
- The migration runs automatically during app startup; no manual SQL action is required in standard deployments.
- All new columns are nullable, so existing rows stay untouched — nothing is backfilled at migration time.
- As with any schema release, we still recommend a database backup and rollout during a low-traffic window.
The migration owner: @arvinxx — responsible for this database schema change, reach out for any migration-related issues.
