assistant: Yep — that’s exactly the intended behavior, with one important nuance:

So:

That’s the job of the watcher state + GitHub Project status:

Then get-unprocessed-ready.mjs will naturally skip it on subsequent runs (until TTL expires), which prevents duplicate work even if something crashes mid-issue.

Agreed — without that, the agent would just stall forever. The updated rules are now:

I’ve already:

Next question: do you want me to also do something about the current stuck state.inProgress entry (I_kwDORJcijc7ooW25)? Options:

State file shows no in-progress or blocked issues.

No further action needed right now. Would you like me to re-run this on a schedule, or check a different project/board?

Yeah for the existing item you can clear it from state.json. I still have another question: when the job runs what happens if it sees multiple items in the GitHub project that are ready for work? Would it process those items sequentially in the same cron worker instance? [message_id: 6c4f174c-2b86-4835-a640-bce65f96e660] assistant: Cleared. I removed I_kwDORJcijc7ooW25 from automation/github-project-watcher/state.json (it had been sitting in processedIssueNodeIds; inProgress was already empty).

On your question: yes—if a given run sees multiple “Ready for work” items, it will process them sequentially in the same cron worker instance, in a deterministic order (sorted by repo then issue number, per get-unprocessed-ready.mjs).

A couple practical notes given the 10-minute cron timeout:

If you want, we can add an explicit “time budget” rule to the payload (e.g., “only start a new issue if ≥2 minutes remain”) to avoid half-starting an issue near timeout. user: So what we're saying is let's say I have five items that are ready for work and it only finishes one in the time minute window. It was in the process of working on the second item when it hits a timeout. What happens next for that second item and the other three items? [message_id: 6352c31a-6c09-4360-b39e-6c078dcb6c60] assistant: Assume 5 items are “Ready for work”, and the worker finishes #1, starts #2, then the cron run times out.

With the updated logic, the first thing it does when it starts an item is:

So when the job dies mid-#2:

On the next cron run:

Net: #2 will be skipped for a while (until you move it back to Ready for work manually, or until the TTL expires and you have logic to re-queue/handle stale inProgress).

Those were never touched, so they remain:

What happens next depends on whether the timed-out run had enough time to mark #2 in progress (usually yes, because it’s step (a) at the top). Either way, on the next run:

Because we’re using a run lock, if the job times out hard and doesn’t execute the “release lock” step, the lock file can be left behind. That’s why the lock has a TTL (default 20 minutes): the next run will treat it as stale, break it, and continue.

If you want the “timed out on #2” case to auto-recover cleanly, the usual improvement is:

Which behavior do you prefer for stale inProgress: auto-retry, auto-block, or leave for manual? user: System: [2026-02-06 14:44:22 UTC] Cron: Run completed.

Summary:

No action required. If you want me to run again on a schedule or force a re-check, tell me and I'll start another run.

I don't want to have to do anything manually other than providing clarifications. That's kind of the whole point of setting up this automatic coding agent process. What do you think will be the most robust way to handle this scenario? [message_id: f5531d42-e730-498b-a4f9-d0e27839dd7c] assistant: If you want zero manual intervention except clarifications, the most robust pattern is to treat each issue like a leased job with automatic retries + an eventual “needs human” escape hatch.

Right now we have the beginnings of that (mark inProgress early), but we’re missing the “what if the worker dies mid-job?” recovery loop.

Here’s what I think is the most robust approach, in order of impact:

Instead of inProgressTtlMinutes = 720 (12h), use something like 30–60 minutes for the automation lease.

This eliminates long “stuck in progress” states without you doing anything.

If the agent is still alive and working, it should periodically “renew” the lease (update startedAt or heartbeatAt) every couple minutes. Then:

That’s how most production queue workers avoid duplication and avoid getting stuck.

Today the cron only queries Ready for work items. For true hands-off automation, the job should do:

My preference: retry automatically unless you’ve built reliable “resume from partial state” logic.

To avoid infinite retry loops (e.g., broken tests, missing secrets, flaky dependency), track attempts per issue, e.g.:

Policy:

This keeps it autonomous but prevents it from burning cycles forever.

This prevents the “starts #2 and dies immediately” scenario.

Example policy:

This dramatically reduces partial work without requiring complex resume logic.

With a 10-minute timeout, processing 5 issues in one run is optimistic.

A very robust strategy is:

This makes timeouts almost irrelevant and naturally smooths load.

Implement: (A) short lease + auto-reclaim + attempts + time budget + 1-issue-per-run.

That combo is boring, simple, and extremely reliable.

No manual cleanup. Only messages you get are:

If you’re aligned, I’d implement next:

Want me to go ahead with that plan, or do you prefer “process as many as possible per run” but with a time budget? user: im not sure... some of these feel way more complicated than it needs to be... my end goal is simply that - i'll create work in my github project and i want the coding agent to pick them up and work on them, ask me for clarifications when needed [message_id: fa58fcac-5ebc-4394-a25c-54f44c361e53] assistant: You’re right to push back. You don’t need a “distributed job system.” You just need two simple guarantees:

We already added (1). The simplest version of (2) that stays low-complexity is:

This is the biggest simplifier.

Why it helps:

We already instructed this:

So if the run dies, at least it’s clearly “owned” and won’t be picked up as Ready by a parallel run.

No manual intervention.

Simplest interpretation:

This can be implemented with minimal extra logic:

That matches your end goal.

5 items ready, it finishes 1 and times out on 2

If we do one issue per run, this basically can’t happen (because it wouldn’t start #2 in that same run). The remaining 4 items just wait for subsequent runs.

If a single issue itself times out mid-work:

No manual cleanup.

When an issue is stale In progress (timed out/crashed), do you want the agent to:

If you say “retry automatically,” I’ll implement a very simple “retry up to 2 times, then block + ask” policy. That keeps it hands-off without getting into complicated systems. user: System: [2026-02-06 14:49:40 UTC] Cron: Run started — lock acquired.

Result:

Lock released. Nothing else to report.

retry automatically. but just to clarify, in this new setup, if something would take longer than 5 mins to complete, would it get stuck forever essentially? bc even if it gets requeued it will time out again next time? [message_id: 72fd8890-00a4-4a84-b0b4-631faec8b1c5] assistant: No — it wouldn’t get stuck forever, but it could get into a dumb retry loop if the per-run time budget is always shorter than the work.

There are three different “takes longer than 5 mins” cases:

Then it’s fine. The cron fires every 5 mins, but the run can last up to timeoutSeconds: 600 (10 mins). With the lock, overlapping ticks just bail.

So “>5 mins” by itself isn’t a problem.

Then yes, with timeoutSeconds=600, you can see:

It still won’t be “stuck forever” if we implement “retry N times then Blocked + ask you”, but it could churn and waste cycles.

This one is actually already handled: we don’t need to wait for merge to make progress. You can mark Done when PR is created, and stop polling merge entirely (or poll briefly). CI can run asynchronously.

Increase the cron job timeout.

If you want this to behave like a real worker, give it room to breathe:

Then combine with:

This keeps logic simple and makes “retry loop” much less likely.

If you keep the schedule at every 5 minutes, that’s fine: the lock will cause most ticks to bail while the long run is active.

Even with longer timeouts, keep:

That guarantees “no manual work except clarifications,” but also “no infinite spinning.”

If you want, I can implement this as:

Do you want 30 minutes or 45 minutes for the job timeout? user: sounds good, timeoutSeconds: 1800 is good, and we can set inProgressTtlMinutes to 30 too [message_id: 3f6dfe74-b1bf-4f91-9cdf-682965357843] assistant: Done.

Changes applied:

One nuance to be aware of (important): for auto-retry to work cleanly, the reclaim script needs the projectItemId recorded in state.inProgress. From this point forward it will be (because we record it when we mark in progress). Older inProgress entries without a stored projectItemId would still be cleared locally, but might need the Project item moved back to “Ready for work” to be picked up again—this should now be handled going forward.

If you want, I can trigger a manual cron run now to sanity-check that:

Details:

No further action required this run. If you want me to re-run now or change the watcher behavior (e.g., relax criteria, run on a different project board), tell me what to do next.

sure go for it [message_id: 1d3cf15d-9b23-4762-9c20-f1685cbc2615] assistant: The scheduler wouldn’t trigger it immediately just now — cron run returned:

That means this cron implementation only allows manual runs when the job is due (some setups enforce that).

Two easy options:

Which do you prefer?