Unbound cron jobs

[wzrayyy]

Problem / Motivation

Is there a reason we forbid creating unbound cron jobs?

cli/commands.py:1883:

if is_bound_cron_job(job):
    return await run_bound_cron_job(job, agent=agent, cron=cron)

reason = "unbound agent cron job must be recreated from a chat session"
logger.warning(
    "Cron: skipped unbound agent job '{}' ({}): {}",
    job.name,
    job.id,
    reason,
)
raise CronJobSkippedError(reason)

Proposed Solution

Creating a new ephemeral session for this job (cron:TIMESTAMP_NS) would be a simple solution, albeit a bit hacky.
Currently the loop expects session key to be set, otherwise fails. Heartbeat and Dream jobs have their own cut down versions of loop, so they are not affected

Related Component

Cron

Additional Context

i'd like to get your input on the proposed solution and rationale behind requiring cron jobs to be bound to a session.

[chengyongru]

hi @wzrayyy

I remember where I explained this, after searching for a while, I finally found it: #1445 (comment)

[wzrayyy]

That's reasonable.
Also, I believe that heartbeats suffer from that problem now)

Although, I was proposing another solution. Here's what I've had in mind: wzrayyy@afa441c. If we do it like that, this would allow for completely headless cron sessions, without any delivery, and just setting it to a new value is fine since in agent/loop.py:1167 we call SessionManager.get_or_create().

What do you think about just plain headless jobs? I have a usecase for this, that's why I'm asking: I'm using nanobot to automate documentation writing for work, and the main problems with the current approach are that the sessions are dirty with previous runs, and that I have to receive countless messages (thankfully in their own Telegram topics, but still). Heartbeat wouldn't work for this, since I want to have granular customization of how often the jobs run, besides, heartbeat doesn't really feel like an appropriate thing to use here.

[chengyongru]

Actually, I generally recommend that tasks be opened in the web UI, which is the inevitable choice. Although third-party chat software is convenient, many functions require native UI support. In addition, regarding context pollution, I suggest you enable session auto compact and set it to 15minutes or even shorter.

[wzrayyy]

In addition, regarding context pollution, I suggest you enable session auto compact and set it to 15minutes or even shorter.

It would still be cleaner to have an option to have a clean session per each run though. Also, it seems that auto compact ignores the cron sessions that do not get any user messages (I'll need to investigate that though, not really certain about this)

[wzrayyy]

Also, it seems that auto compact ignores the cron sessions that do not get any user messages (I'll need to investigate that though, not really certain about this)

I was partially correct on this: it still keeps the last cron run, Consolidator.compact_idle_session finds the last user message and compacts up to it.
What I propose is to instead have a clean session every time cron runs.

[wzrayyy]

Besides, auto compaction is more of a hack, rather than a perfect solution. It is global, I have a cron job that runs every 10m, but I don't want my sessions to compact after 10 minutes.
A targeted option to create new isolated sessions for cron would be really nice 🥺

[wzrayyy]

Would you perhaps like something like this (though I still like isolated sessions more)? Just archiving the session pre/post run (whichever you like more)
wzrayyy@fe32799

I'm still hung up on the idea of having clean sessions for each cron run. 👉 👈