Overview - Ghost

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Failed
30214
e7d645ef Migrated clean-gifts to the class-based jobs service ref https://linear.app/ghost/issue/HKG-1975 The legacy bree worker did no work: it posted a domain event back to the main thread and reported "done" immediately, so job success and duration were meaningless. Dispatching a CleanGiftsJob through the jobs service runs the same code on the same thread, but job.completed now fires when cleanup actually finishes. The worker, the domain event and the legacy registration go in the same commit so the job is never registered in both systems. Scheduling moves to initBackgroundServices because gifts init() runs before the jobs service exists. The old started/completed logs are replaced by a structured clean_gifts.completed event whose counts start at null, not zero, so a phase whose swallowed error skipped it doesn't look idle.
by Fabien O'C...
Succeeded
30214
4a9bf3b6 Migrated clean-gifts to the class-based jobs service ref https://linear.app/ghost/issue/HKG-1975/migrate-clean-gifts-to-the-durable-jobs-interface The legacy clean-gifts job was a bree worker that did no work: it posted a domain event back to the main thread, reported "done" immediately, and the real cleanup ran in a subscription in the gifts service. That made the job manager's success signal and its duration meaningless. Replacing the worker plus event with a CleanGiftsJob dispatched through the jobs service keeps the work on exactly the same thread it already ran on, and makes job.completed fire when the cleanup actually finishes. The worker file, the domain event and the legacy addJob registration all go in this commit so the job is never registered in both systems. The schedule keeps its 0-5am off-peak random cron - clean-tokens uses the full day, which would be wrong here - and takes the jobs service as an argument instead of resolving the singleton itself, so scheduling is testable with a plain stub. Scheduling has to move out of the gifts service, because gifts init() runs before the jobs service exists. It lands in initBackgroundServices ahead of activitypub.init(), for the same reason the interrupted-send recovery above it does: initBackgroundServices is fire-and-forget, so an unrelated background service rejecting would otherwise leave gifts uncleaned for the life of the process, silently. The subscription's outer started/completed logs are dropped: the jobs service already emits both generically. The per-phase counts they left behind are now carried by a structured clean_gifts.completed event logged from cleanup() itself. Its counters start at null rather than zero - cleanup() swallows per-phase errors to preserve the old behaviour, so a zero would make a phase that has failed every night look like a phase with nothing to do.
by Fabien O'C...
Failed
30214
5a893da5 Migrated clean-gifts to the class-based jobs service ref https://linear.app/ghost/issue/HKG-1975/migrate-clean-gifts-to-the-durable-jobs-interface The legacy clean-gifts job was a bree worker that did no work: it posted a domain event back to the main thread, reported "done" immediately, and the real cleanup ran in a subscription in the gifts service. That made the job manager's success signal and its duration meaningless. Replacing the worker plus event with a CleanGiftsJob dispatched through the jobs service keeps the work on exactly the same thread it already ran on, and makes job.completed fire when the cleanup actually finishes. The worker file, the domain event and the legacy addJob registration all go in this commit so the job is never registered in both systems. The schedule keeps its 0-5am off-peak random cron - clean-tokens uses the full day, which would be wrong here - and takes the jobs service as an argument instead of resolving the singleton itself, so scheduling is testable with a plain stub. Scheduling has to move out of the gifts service, because gifts init() runs before the jobs service exists. It lands in initBackgroundServices ahead of activitypub.init(), for the same reason the interrupted-send recovery above it does: initBackgroundServices is fire-and-forget, so an unrelated background service rejecting would otherwise leave gifts uncleaned for the life of the process, silently. The subscription's outer started/completed logs are dropped: the jobs service already emits both generically. The per-phase counts they left behind are now carried by a structured clean_gifts.completed event logged from cleanup() itself. Its counters start at null rather than zero - cleanup() swallows per-phase errors to preserve the old behaviour, so a zero would make a phase that has failed every night look like a phase with nothing to do.
by Fabien O'C...
Failed
30214
8ddfb53d Migrated clean-gifts to the class-based jobs service ref https://linear.app/ghost/issue/HKG-1975/migrate-clean-gifts-to-the-durable-jobs-interface The legacy clean-gifts job was a bree worker that did no work: it posted a domain event back to the main thread, reported "done" immediately, and the real cleanup ran in a subscription in the gifts service. That made the job manager's success signal and its duration meaningless. Replacing the worker plus event with a CleanGiftsJob dispatched through the jobs service keeps the work on exactly the same thread it already ran on, and makes job.completed fire when the cleanup actually finishes. The worker file, the domain event and the legacy addJob registration all go in this commit so the job is never registered in both systems. The schedule keeps its 0-5am off-peak random cron - clean-tokens uses the full day, which would be wrong here - and takes the jobs service as an argument instead of resolving the singleton itself, so scheduling is testable with a plain stub. Scheduling has to move out of the gifts service, because gifts init() runs before the jobs service exists. It lands in initBackgroundServices ahead of activitypub.init(), for the same reason the interrupted-send recovery above it does: initBackgroundServices is fire-and-forget, so an unrelated background service rejecting would otherwise leave gifts uncleaned for the life of the process, silently. The subscription's outer started/completed logs are dropped: the jobs service already emits both generically. The per-phase counts they left behind are now carried by a structured clean_gifts.completed event logged from cleanup() itself. Its counters start at null rather than zero - cleanup() swallows per-phase errors to preserve the old behaviour, so a zero would make a phase that has failed every night look like a phase with nothing to do.
by Fabien O'C...
Failed
30214
cf9a6f5a Migrated clean-gifts to the class-based jobs service ref https://linear.app/ghost/issue/HKG-1975/migrate-clean-gifts-to-the-durable-jobs-interface The legacy clean-gifts job was a bree worker that did no work: it posted a domain event back to the main thread, reported "done" immediately, and the real cleanup ran in a subscription in the gifts service. That made the job manager's success signal and its duration meaningless. Replacing the worker plus event with a CleanGiftsJob dispatched through the jobs service keeps the work on exactly the same thread it already ran on, and makes job.completed fire when the cleanup actually finishes. The worker file, the domain event and the legacy addJob registration all go in this commit so the job is never registered in both systems. The schedule keeps its 0-5am off-peak random cron - clean-tokens uses the full day, which would be wrong here - and takes the jobs service as an argument instead of resolving the singleton itself, so scheduling is testable with a plain stub. Scheduling has to move out of the gifts service, because gifts init() runs before the jobs service exists. It lands in initBackgroundServices ahead of activitypub.init(), for the same reason the interrupted-send recovery above it does: initBackgroundServices is fire-and-forget, so an unrelated background service rejecting would otherwise leave gifts uncleaned for the life of the process, silently. The subscription's outer started/completed logs are dropped: the jobs service already emits both generically. The per-phase counts they left behind are now carried by a structured clean_gifts.completed event logged from cleanup() itself. Its counters start at null rather than zero - cleanup() swallows per-phase errors to preserve the old behaviour, so a zero would make a phase that has failed every night look like a phase with nothing to do.
by Fabien O'C...
Succeeded
30214
2ad6b174 Migrated clean-gifts to the class-based jobs service ref https://linear.app/ghost/issue/HKG-1975/migrate-clean-gifts-to-the-durable-jobs-interface The legacy clean-gifts job was a bree worker that did no work: it posted a domain event back to the main thread, reported "done" immediately, and the real cleanup ran in a subscription in the gifts service. That made the job manager's success signal and its duration meaningless. Replacing the worker plus event with a CleanGiftsJob dispatched through the jobs service keeps the work on exactly the same thread it already ran on, and makes job.completed fire when the cleanup actually finishes. The worker file, the domain event and the legacy addJob registration all go in this commit so the job is never registered in both systems. The schedule keeps its 0-5am off-peak random cron - clean-tokens uses the full day, which would be wrong here - and takes the jobs service as an argument instead of resolving the singleton itself, so scheduling is testable with a plain stub. Scheduling has to move out of the gifts service, because gifts init() runs before the jobs service exists. It lands in initBackgroundServices ahead of activitypub.init(), for the same reason the interrupted-send recovery above it does: initBackgroundServices is fire-and-forget, so an unrelated background service rejecting would otherwise leave gifts uncleaned for the life of the process, silently. The subscription's outer started/completed logs are dropped: the jobs service already emits both generically. The per-phase counts they left behind are now carried by a structured clean_gifts.completed event logged from cleanup() itself. Its counters start at null rather than zero - cleanup() swallows per-phase errors to preserve the old behaviour, so a zero would make a phase that has failed every night look like a phase with nothing to do.
by Fabien O'C...