AkkomaGang/akkoma

Fork 103

[bug] DigestEmailsWorker jobs fill avaialable queue without clearing #924

New issue

Closed

opened 2025-05-11 17:29:03 +00:00 by norm · 3 comments

norm commented

2025-05-11 17:29:03 +00:00

Contributor

Your setup

From source

Extra details

Fedora 42

Version

30b1684e28

PostgreSQL version

What were you trying to do?

Jobs from Pleroma.Workers.Cron.DigestEmailsWorker fills the available queue, even if digest emails are disabled in the config.

This example shows a job scheduled 17 h ago but has not actually been executed or completed.

What did you expect to happen?

Job is not scheduled into the available queue, leaving it free for other jobs.

What actually happened?

Job isn't run, but fills available queue.

Logs

No response

Severity

I can manage

Have you searched for this issue?

I have double-checked and have not found this issue mentioned anywhere.

### Your setup From source ### Extra details Fedora 42 ### Version 30b1684e28f3a945c7e8a3cb464e21d425e26981 ### PostgreSQL version 17 ### What were you trying to do? Jobs from `Pleroma.Workers.Cron.DigestEmailsWorker` fills the available queue, even if digest emails are disabled in the config. This example shows a job scheduled 17 h ago but has not actually been executed or completed. ![image](/attachments/b0cac385-8a96-4b92-afa0-7c33877e9437) ### What did you expect to happen? Job is not scheduled into the available queue, leaving it free for other jobs. ### What actually happened? Job isn't run, but fills available queue. ### Logs _No response_ ### Severity I can manage ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

image.png

69 KiB

norm added the

bug

label 2025-05-11 17:29:03 +00:00

Oneric commented

2025-05-11 20:43:47 +00:00

Owner

Adding some more details and context:

DigestemailWorker is a oban cron job running once per week (see "cron" => "true" and the cron_expr term in the screenshot). It’s scheduling is defined in the default config under :pleroma, Oban, :crontab.

Thus a single available job hanging around for a week might at first seem fine and the worker code itself also suggests it will just check the setting at runtime and exit as a noop if not enabled.
However checking my own DB the job’s are only inserted once they are available for scheduling (inserted_at and scheduled_at columns match for all entries)) and for me all jobs since the instance’s creation are still hanging around. Checking Prometheus stats confirms no single DigestEmailsWorker ever failed or succeeded.

The other too cron jobs though, NewUserDigestWorker and PruneDatabaseWorker are regularly running fine and do not get stuck in available.

I’m not sure how/why cron jobs work at all given Oban docs instruct us to configure them by enabling Oban.Plugins.Cron and passing the crontab settings to the plugin instead of being top-level Oban setting.

Adding some more details and context: `DigestemailWorker` is a oban cron job running once per week *(see `"cron" => "true"` and the `cron_expr` term in the screenshot)*. It’s scheduling is defined in the default config under `:pleroma, Oban, :crontab`. Thus a single `available` job hanging around for a week might at first seem fine and the worker code itself also suggests it will just check the setting at runtime and exit as a noop if not enabled. However checking my own DB the job’s are only inserted once they are available for scheduling (`inserted_at` and `scheduled_at` columns match for all entries)) and for me **all** jobs since the instance’s creation are still hanging around. Checking Prometheus stats confirms no single `DigestEmailsWorker` ever failed or succeeded. The other too cron jobs though, `NewUserDigestWorker` and `PruneDatabaseWorker` are regularly running fine and do not get stuck in `available`. I’m not sure how/why cron jobs work at all given Oban docs instruct us to configure them by enabling `Oban.Plugins.Cron` and passing the `crontab` settings to the plugin instead of being top-level Oban setting.

Oneric commented

2025-05-11 20:52:50 +00:00

Owner

It appears the queue isn’t properly registered:

# use Oban.Worker, queue: "digest_emails"
iex(akkoma@localhost)7> Oban.check_queue(queue: "digest_emails")
nil

# use Oban.Worker, queue: "database_prune"
iex(akkoma@localhost)8> Oban.check_queue(queue: "database_prune")
%{
  name: Oban,
  node: "akkoma@localhost",
  running: [],
  queue: "database_prune",
  started_at: ~U[2025-05-10 00:01:58.705998Z],
  limit: 1,
  updated_at: ~U[2025-05-11 20:50:47.366055Z],
  uuid: "ebf3a2b8-fe6c-4854-973e-7ed4fd602b16",
  paused: false,
  refresh_interval: 30000,
  shutdown_started_at: nil
}

# use Pleroma.Workers.WorkerHelper, queue: "new_users_digest"
iex(akkoma@localhost)6> Oban.check_queue(queue: "new_users_digest")
%{
  name: Oban,
  node: "akkoma@localhost",
  running: [],
  queue: "new_users_digest",
  started_at: ~U[2025-05-10 00:01:58.705925Z],
  limit: 1,
  updated_at: ~U[2025-05-11 20:49:08.811032Z],
  uuid: "4c5417b2-2814-4c82-89f9-99a50d230f75",
  paused: false,
  refresh_interval: 30000,
  shutdown_started_at: nil
}

It appears the queue isn’t properly registered: ```elixir # use Oban.Worker, queue: "digest_emails" iex(akkoma@localhost)7> Oban.check_queue(queue: "digest_emails") nil # use Oban.Worker, queue: "database_prune" iex(akkoma@localhost)8> Oban.check_queue(queue: "database_prune") %{ name: Oban, node: "akkoma@localhost", running: [], queue: "database_prune", started_at: ~U[2025-05-10 00:01:58.705998Z], limit: 1, updated_at: ~U[2025-05-11 20:50:47.366055Z], uuid: "ebf3a2b8-fe6c-4854-973e-7ed4fd602b16", paused: false, refresh_interval: 30000, shutdown_started_at: nil } # use Pleroma.Workers.WorkerHelper, queue: "new_users_digest" iex(akkoma@localhost)6> Oban.check_queue(queue: "new_users_digest") %{ name: Oban, node: "akkoma@localhost", running: [], queue: "new_users_digest", started_at: ~U[2025-05-10 00:01:58.705925Z], limit: 1, updated_at: ~U[2025-05-11 20:49:08.811032Z], uuid: "4c5417b2-2814-4c82-89f9-99a50d230f75", paused: false, refresh_interval: 30000, shutdown_started_at: nil } ```

Oneric commented

2025-05-11 21:16:29 +00:00

Owner

Should be fixed by #925 although I’m a bit baffled by the implication of digest emails being completely non-functional for 6 years without anyone noticing and complaining, digest emails being disabled by default notwithstanding. Perhaps this just means no one is actually using them (and hence we could just drop it without anyone caring).

Should be fixed by #925 although I’m a bit baffled by the implication of digest emails being completely non-functional for 6 years without anyone noticing and complaining, digest emails being disabled by default notwithstanding. Perhaps this just means no one is actually using them *(and hence we could just drop it without anyone caring)*.

norm referenced this issue

2025-05-11 22:55:33 +00:00

Properly register digest_emails queue #925