# `Tayori.Jobs`
[🔗](https://github.com/hattoriai/tayori/blob/v0.1.0/lib/tayori/jobs.ex#L1)

What a publication sends, and how: the emails to the subscribers (the
`:subscriptions` feature), the webhooks (the `:webhooks` feature) and
the call to the app's `:notifier`.

An entry is announced once, by one node of the cluster, when it is
published or when its scheduled time comes (the entry is claimed in the
database first). Its readers see it on time whatever happens next: what
follows is only what it sends.

The schedules go the same way: a digest of the inbox (`Tayori.Digest`),
and, with the `:emails` config, the email of a period's entries to
each subscriber. A digest is one job at a time: asked for again while
one waits, it is the same job, which takes the changes that came
meanwhile.

## With Oban

When the app runs [Oban](https://hexdocs.pm/oban), Tayori gives it the
work, as jobs of `Tayori.Worker`:

    {Tayori, repo: MyApp.Repo, pubsub: MyApp.PubSub, oban: Oban}

Each email, each webhook and the notifier's call is a job of its own,
retried with Oban's backoff, through deploys and crashes, and seen in
Oban's dashboards. A webhook a place refuses for good (a 4xx) is
cancelled, not retried. The jobs go to the `:default` queue, or the
one given (`oban: [name: Oban, queue: :news]`), which must be one the
app runs: Tayori logs an error when it is not.

`mix tayori.install` sets `oban: Oban` when the app has Oban.

## Without Oban

Tayori sends them from tasks in the node that announced the entry. A
webhook is tried three times, a few seconds apart; an email and a
digest once. A failure is logged. A node stopped while it sends (a deploy, a crash)
loses what it had not sent yet: the entry is not sent twice, but some
subscribers may not get it. For a changelog with subscribers or
webhooks that matter, run Oban.

---

*Consult [api-reference.md](api-reference.md) for complete listing*