When part of a task runs long, DataMind Oda can keep it running in the background as a job while you carry on in the chat. This page covers how jobs are owned, kept and limited; Background jobs shows how to start, read and stop them.
Each job belongs to the chat that started it. Another chat cannot read it or stop it: a read from elsewhere is refused with job <id> belongs to another session. Read and stop a job from the chat it belongs to.
Each job has a kind and an id that starts with it, such as bash-1 for a command run in the background or subagent-1 for a helper run.
unknown job <id>.Stopping is a request, not an instant stop. Oda asks the job to stop, and the job ends as killed once its work actually stops. A job that had already finished is not affected. To stop a job, see Background jobs.
Archiving a chat stops the work it was running, including its background jobs. Oda stops the chat's running and stopping jobs one at a time; each ends as killed with the reason session archived. If one job fails to stop, the others still do. The archiving itself is covered in Stopping Oda and queued messages.
One chat can have up to 10 jobs in progress at the same time. Jobs that are still stopping count towards the limit; jobs that have finished do not.
When all 10 places are taken, a new job does not start and does not wait in line, and nothing is pushed out to make room. The refusal reads background job limit reached for this owner (limit: 10), and the way to make room is to stop an unneeded job, wait for one to finish, then try again.
Oda keeps a job's output within a size limit, and output beyond it is dropped from memory.
Up to 10 in one chat at a time. Jobs that are still stopping count towards the limit; finished jobs do not. When every place is taken, nothing new starts and nothing waits in line.
Stopping is a request: a job keeps its place until its work actually stops. Once it does, the job reads as killed and its place is free.
Oda stops the chat's running and stopping jobs, one at a time. Each ends as killed, with the reason session archived. The archiving itself is covered in Stopping Oda and queued messages.
No. Jobs live only while Oda runs, and they end when it closes. After a restart, an id from before reports as unknown job <id>; ask Oda to run the work again if you still need it.
No. A job belongs to the chat that started it, and a read from elsewhere is refused with job <id> belongs to another session. Read and stop it from the chat it belongs to.
unknown job <id>?The app has no job with that id: it may have been cleared, or Oda may have restarted since the job ran. If the work still matters, ask Oda to run it again.
No. Following a job and reading it with Oda are separate; watching consumes nothing, and each piece of output is delivered to Oda once.
While it runs, up to 256 KB of its newest output. After it settles, at least the newest 16 KB, together with anything Oda has not read yet. Output beyond that is dropped, and a read that asks for dropped output says so instead of failing.