The Field That Decides Your Next Task ID Isn’t What You Think

ID reuse in a task tracker is a scheduling fault where the system treats a task with a missing review-date field as unresolved and returns its existing ID instead of incrementing to the next one.

The incident that made the bug visible

On 2026-08-30, the scheduler returned D-20260830-03 twice in a row. The first time was correct — the task was new. The second time was not. The task had already been registered and logged as reviewed. The counter looked fine; no error was thrown; 44 self-tests passed without damage.

The fault was quieter than a crash. The scheduler was not broken — it was reading one field, finding it empty, and behaving exactly as designed.

That field was the review date. When it reads “none,” the scheduler treats the task as unresolved. An unresolved task does not increment the counter. So the system handed back the same ID it had just issued.

What the three-source cross-check found

Three independent checks ran against the same task log: our own tracker (OOK, reading 12), a second system (UNIS, reading 01), and a deduplication pass (--check-dup). OOK and UNIS reported normally. --check-dup returned zero duplicates.

That result looks like a clean bill of health. It isn’t. Zero duplicates means no two open records share an ID — which is true, because the reuse happened between a closed-looking record and the next issuance, not between two simultaneous open records. The deduplication check was asking the right question about the wrong moment in the sequence.

The fault only became unambiguous when fault injection disabled the review-date axis entirely. The scheduler immediately reverted to D-20260830-03. That single test identified the axis that drives the ID decision: not the counter, not the deduplication logic — the review-date field.

Why this pattern is structural, not accidental

The underlying logic is defensible: if a task has no confirmed review date, the system has no proof it was resolved, so it refuses to move past it. The problem is that “no review date” and “not yet reviewed” look identical to the scheduler. A legitimate reason to omit the date — the field was optional, the UI skipped it, the import script left it blank — produces the same behavior as a genuinely unresolved task.

Fixing the counter without filling the field does nothing. The counter increment is downstream of the field read. The system will override it on the next call.

This is the same structural error that appears in a different domain with AI-generated content: a system trained on a narrow signal — in the case documented by TechCrunch on September 3, 2026, restaurant menu illustrations trained on a “pleasing aesthetic” — produces outputs that look correct until a second look reveals they are all the same. The surface (ID, illustration) varies; the hidden driver (field value, training distribution) does not. The fix lives at the driver, not the surface.

What the self-test suite missed — and why

The self-test ran 44 cases and passed all of them. That is not a failure of the test suite; it is a boundary condition. The tests verify what the scheduler does with well-formed inputs. A missing review-date field is not a malformed input — it is a valid state the schema permits. The suite never exercised the combination of “field present but blank” followed immediately by --next.

This is a coverage gap, not a bug in the tests. The distinction matters for how you close it: adding a test that seeds a blank review-date field and calls --next would have caught the fault before it reached the live log.

The decision rule for anyone building a similar system

Three actions close this class of fault permanently.

Make the review-date field required at write time, not optional. If the field can be blank, the scheduler will eventually encounter a blank. Optional fields that drive branching logic are faults waiting for the right input.

Add a --next pre-flight check. Before issuing an ID, the scheduler should assert that the current task has a non-empty review date. If it does not, it should surface an error rather than silently reusing the ID. Silent reuse is the expensive part — it produces duplicate IDs in downstream records that look legitimate.

Include a blank-field seed in the self-test suite. A test that writes a task with no review date, calls --next, and asserts the result is a new ID would have failed before the live incident. One test case, added once, eliminates the coverage gap permanently.

The 44 passing tests represent real coverage. They do not represent complete coverage. The self-test suite is not a proof of correctness — it is a probe of the states you thought to test. The state you forgot to test is the one that reaches production.

What this means for anyone reading task logs

If your tracker issues the same ID twice and the counter looks correct, do not start with the counter. Start with the field that the scheduler reads to decide whether to increment. In this system, that field is the review date. In yours, it may be a status flag, a close timestamp, or an approval field — but the pattern is the same: the ID decision lives upstream of the counter, in a field that can be blank without triggering a validation error.

A duplicate ID in a task log is not evidence the ID system is broken. It is evidence that one upstream field contains a value the scheduler reads as “not done yet.” Find that field, fill it, and the counter corrects itself on the next call.

Looking for more on ai & digital income? Visit SAVYX

Frequently Asked Questions

Why does my task tracker return the same ID twice even though the counter looks correct?

The ID counter is downstream of a field the scheduler reads first — in the measured incident, the review-date field. When that field is blank, the scheduler treats the task as unresolved and reissues the current ID rather than incrementing. Fixing the counter value without filling the field has no effect.

Will a deduplication check catch this kind of ID reuse?

Not reliably. A deduplication check compares open records against each other. The reuse happens between a closed-looking record and the next issuance — two different moments, not two simultaneous open records. The measured `–check-dup` pass returned zero duplicates even while the fault was active.

How do I find which field is driving the ID decision in my own system?

Disable the candidate field — set it blank or remove it — and call the ID-generation function immediately after marking a task resolved. If the system reverts to the previous ID, that field is the decision axis. Fault injection of this kind is what identified the review-date axis in the 2026-08-30 incident.

Why did 44 passing self-tests not catch this fault?

The tests verified well-formed inputs. A blank review-date field is a valid schema state, not a malformed input, so it was never seeded in the test suite. The gap is a coverage boundary, not a test-suite failure — closing it requires one test that writes a blank field and asserts the next call increments the ID.

What is the fastest fix if I am seeing duplicate IDs in a live log right now?

Locate the most recent task whose review-date field (or equivalent status field) is blank and fill it with the correct resolved date. Then call `–next` again. The scheduler should issue the incremented ID. Confirm with your deduplication check after the field is populated, not before.

Disclosure: As an affiliate, this post may earn a commission from qualifying purchases at no extra cost to you.