We want timed custom prompts — summarise my open deals every weekday at 8, with no browser open. The scheduler is already the right shape for it and every custom prompt lane already is a source, so the feature is close to an existing rrext_deploy schedule_set call. What sits between them: a scheduled start delivers no payload, and no source node in the catalogue fires on a timer.
Filed from section 5.1 of the Rocket CRM runtime findings (docRevision 252). Part of the Rocket CRM build tracked in rocketride-ai/rocketride-saas#456. Named but explicitly not filed in #2045's "Related, not filed" list.
Mechanism
Both the scheduler and a manual deploy run do the same thing:
pipeline = dict(artifact)
pipeline['source'] = source_id
await start_server_task_as_team(...)
The source is expected to pull its own input. There are six source-class nodes in the whole catalogue: core/filesys, telegram, and four webhook variants. A webhook is passive; it listens until ttl expires. Point a cron at a prompt lane today and you get a task that sits there and dies quietly — no error, no run, nothing to notice.
The wrinkle in our favour
The prompt node emits its merged question whenever the pipe closes, empty or not. That is the same behaviour that caused a double-answer bug on our chat path, and for a digest it is precisely right: there is no material, the saved instructions are the input. A lane needs no payload at all. It needs something to knock on the door. (This is why the emission-model issue filed alongside this one asks for an explicit flag rather than a behaviour change.)
What we do today
Nothing — timed prompts cannot ship.
Ask
- A timer or tick source node: a seventh source class that opens and closes a pipe on start and emits nothing. This is the smallest general fix, and it makes every scheduled pipeline in the catalogue possible rather than just ours.
- Or let the scheduler carry an optional payload on the schedule row and deliver it to the source. That is a scheduled webhook post by another name, and strictly more useful, since a digest could then be parameterised.
This also argues for lazy lane activation (section 2.5): a scheduled lane is exactly a lane that should not be resident between fires.
Related
We want timed custom prompts — summarise my open deals every weekday at 8, with no browser open. The scheduler is already the right shape for it and every custom prompt lane already is a source, so the feature is close to an existing
rrext_deploy schedule_setcall. What sits between them: a scheduled start delivers no payload, and no source node in the catalogue fires on a timer.Filed from section 5.1 of the Rocket CRM runtime findings (docRevision 252). Part of the Rocket CRM build tracked in rocketride-ai/rocketride-saas#456. Named but explicitly not filed in #2045's "Related, not filed" list.
Mechanism
Both the scheduler and a manual deploy run do the same thing:
The source is expected to pull its own input. There are six source-class nodes in the whole catalogue:
core/filesys,telegram, and four webhook variants. A webhook is passive; it listens until ttl expires. Point a cron at a prompt lane today and you get a task that sits there and dies quietly — no error, no run, nothing to notice.The wrinkle in our favour
The
promptnode emits its merged question whenever the pipe closes, empty or not. That is the same behaviour that caused a double-answer bug on our chat path, and for a digest it is precisely right: there is no material, the saved instructions are the input. A lane needs no payload at all. It needs something to knock on the door. (This is why the emission-model issue filed alongside this one asks for an explicit flag rather than a behaviour change.)What we do today
Nothing — timed prompts cannot ship.
Ask
This also argues for lazy lane activation (section 2.5): a scheduled lane is exactly a lane that should not be resident between fires.
Related