schedule.store_required

An app has a schedule but no database named to keep its state in, because it has several databases or none.

Area 12, Background work; not declinable; the next step is usually the human's.

Why Jadpo refuses it

Each schedule keeps its next due time and its lease, the claim that stops two copies of your app running it at once, in a database. With one database that is the one. With several, any of them could hold it, and Jadpo won't choose one for you: application { schedules: { store: } } names it, and with no database at all there is nowhere to keep it.

What it looks like

domains/planning/schedules/tidy_up.jadpo, in an app with two databases, archive and main:

use planning/actions { tidy }/// Tidies up every quarter of an hour.schedule tidy_up {    every: 15m    run: tidy()}

  |4 | schedule tidy_up {  |          ^^^^^^^ no store for its state

(human) at the end of the next: line tells your coding agent to stop and ask you which fix you want, because the choice is yours to make: it decides which database keeps the state of every schedule in the app.

An entity whose lifecycle has purge: gets a schedule that Jadpo writes for it, which deletes its old records every hour. It keeps its state in the same database as every other schedule, so with several databases the lifecycle's purge: is refused the same way. Here Todo is kept in main:

/// Something to do.entity Todo {    id: Uuid    deleted_at: Instant?    store: main    lifecycle: {        visible: deleted_at == none        transitions: {            delete: {                when: deleted_at == none                set: {                    deleted_at: clock.now                }            }        }        purge: {            after: 30d            since: deleted_at        }    }}

   |18 |         purge: {   |         ^^^^^ a schedule with no store for its state

How to fix it

The question is which database should keep the schedules' state. It holds every schedule's state, the purge schedules' included, so one database answers it for the whole app.

If one database should keep it, name it in schedules: in app.jadpo. The next step suggests the first of them, here archive:

    schedules: {        store: archive    }

Each schedule's next due time, lease and run records are now kept in archive, in system tables its first migration creates.

If the schedule is an entity's purge, the next step suggests the entity's own database. For Todo, kept in main:

    schedules: {        store: main    }

Todo.purge's state and run records are now kept in main, beside the Todo records it deletes.

Related

• Where a schedule's state is kept
• The purge schedule
• Schedules
• Stores