pub struct AppScheduleManifest {
pub id: String,
pub cron: String,
pub capability: String,
pub payload: Option<Value>,
}Expand description
One recurring job an app declares in its own manifest, so the host can put the cron row on the node without the app ever having run (econ-v1/node#3185).
Before this existed, an app that records on a schedule had to register its
own row when it started — which a lazy app only does once something first
invokes it. On a node whose owner never opens that app, the row was never
created, nothing was ever recorded, and nothing said so.
Declaring the schedule here does NOT make the app resident. The host
registers a CAPABILITY-triggered row pointing at Self::capability; when
it fires, the capability router resolves the provider from the registry
(seeded at boot for unloaded apps) and cold-starts the app for the duration
of the call. Between firings the isolate can be reclaimed exactly as before.
auto_start: "auto" would also produce the row, and is NOT the answer: it
pins the isolate permanently, which is the cost a sparse cadence exists to
avoid.
Fields§
§id: StringStable identifier, unique within this app. Becomes the cron row’s
external_id (paired with the app name as external_type), which is
what lets the host find its own row again without storing anything.
Changing it retires the old row and creates a new one — it is an identity, not a label.
cron: String6-field cron expression: sec min hour day month weekday.
Checked here only for shape (six non-empty fields over the permitted
character set). The authoritative parse lives in the host, which refuses
the whole manifest on a bad expression — this crate is the schema
contract that app authors compile against, and is deliberately kept to
serde alone rather than pulling a cron parser and its date-time
dependencies into every app build.
capability: StringThe capability the row dispatches.
MUST be one this same app declares in provides / capabilities.provides,
and the manifest is refused otherwise. Without that restriction any
manifest could schedule repeated dispatches at any capability on the node
— core.lightning.send_payment, say — and a manifest is not a surface
the owner reviews.
payload: Option<Value>JSON object handed to the capability on each firing. Absent means {}.
A non-object payload is refused: every capability on the dispatch path
takes an object, and the router stamps caller into it.
Implementations§
Source§impl AppScheduleManifest
impl AppScheduleManifest
Sourcepub fn effective_payload(&self) -> Value
pub fn effective_payload(&self) -> Value
The payload to dispatch with, defaulting to an empty object.