termux-job-scheduler: New jobs default to job ID 0

[Terrance]

Problem description

When creating a new job, with no ID given it assumes ID 0 and replaces an existing job of that ID.

Steps to reproduce

$ termux-job-scheduler -s ~/jobs/one.sh --period-ms 14400000
Scheduling Job 0: /data/data/com.termux/files/home/jobs/one.sh       (periodic: 14400000ms) ... - response 1

$ termux-job-scheduler -s ~/jobs/two.sh --period-ms 14400000
Scheduling Job 0: /data/data/com.termux/files/home/jobs/two.sh       (periodic: 14400000ms) ... - response 1

Expected behavior

I'd expect the default behaviour to choose the next available job number and not replace an existing job.

  --job-id int               job id (will overwrite any previous job with the same id)

This reads to me like it will override a job only if you explicitly give it an existing job ID (it doesn't specify a default of 0).

Additional information

$ termux-info
Termux Variables:
TERMUX_APP_PACKAGE_MANAGER=apt
TERMUX_MAIN_PACKAGE_FORMAT=debian
TERMUX_VERSION=0.118.0
Packages CPU architecture:
aarch64
Subscribed repositories:
# sources.list
deb https://grimler.se/termux/termux-main stable main
Updatable packages:
All packages up to date
termux-tools version:
1.31.0
Android version:
12
Kernel build information:
Linux localhost 4.19.157-perf+ #1 SMP PREEMPT Sat Sep 17 00:13:28 CST 2022 aarch64 Android
Device manufacturer:
OnePlus
Device model:
EB2103

[agnostic-apollo]

default behaviour to choose the next available job number

Then termux would have to store and skip every custom job number a user passes and remove them. Current way allows user to control the behaviour and how it should be. But a note in the help doc that the default is 0 would be a good idea.

[Terrance]

How about just taking max(existing job IDs) + 1 as the next job ID? You're guaranteed a unique ID without having to store anything extra, though I don't know the overhead of needing to list existing jobs. The ID it chooses might not be ideal if you've curated your existing IDs, but at that point you should already know about --job-id and can choose better IDs if needed.

[agnostic-apollo]

A user may themselves pass max+1 later which would replace the previous job.

[Terrance]

To clarify, are you referring to users who have their own tools (wrapping termux-job-scheduler) to create jobs, and track their own job IDs? If so then yes, if they then created a job outside of their tooling and it claimed the next ID, their tools would need to look for that, but again I would have thought there'd be enough awareness of job IDs at that point that they'd need to give it a non-conflicting one.

I suppose an alternative is just taking the first available job ID, and suggest that users managing their own fleet of jobs choose sufficiently high job IDs to avoid conflicts.

Making the ID 0 default clearer avoids these problems, but it feels like it's making what I'd expect to be the more general case (just ad-hoc scheduling multiple jobs) a pain: as it stands, I have to check the job list to find the current max ID, and then specify a free ID for each new job.

[agnostic-apollo]

To clarify, are you referring to users who have their own tools (wrapping termux-job-scheduler) to create jobs, and track their own job IDs?

Yes. If a job id wasn't passed, and termux chooses its own, it may break cases when chosen id is also selected by wrappers/users.

I guess a --job-id=auto should cover all cases, while default is still 0 to keep backward compatibility. I think that should work for you.