Bug: ID collision after deleting items causes duplicate IDs

[manish-jangra]

Description

The create_item() function generates new item IDs using len(_get_items()) + 1. This approach causes duplicate IDs when items are deleted from the middle or beginning of the list.

Steps to Reproduce

1. Create item A → id=1
2. Create item B → id=2
3. Delete item A (id=1) — list now contains only item B (id=2), length = 1
4. Create item C → len([B]) + 1 = 2 → id=2 (duplicate!)

Now two items (B and C) both have id=2.

Expected Behavior

Each item should have a globally unique ID that is never reused, regardless of deletions.

Actual Behavior

IDs can collide after deletions because the ID generation is based on the current list length rather than a monotonically increasing counter.

Impact

• PATCH /items/:id and DELETE /items/:id will only operate on the first item found with the duplicate ID (via next()), making the second item inaccessible.
• Clients caching items by ID will get stale/incorrect data.

Suggested Fix

Replace the length-based ID with an auto-incrementing counter:

_next_id = 1

def _new_id():
    global _next_id
    current = _next_id
    _next_id += 1
    return current

And update create_item():

item = {
    "id": _new_id(),
    "name": data["name"],
    "done": False,
}

Also update reset_items() to reset the counter for tests:

def reset_items():
    global _next_id
    _items_store.clear()
    _next_id = 1

Affected File

• app.py — create_item() function (line ~29)

[fullsend-ai-triage]

Triage Summary

Severity: High · Category: Bug

Problem

The create_item() function generates IDs via len(_get_items()) + 1. When items are deleted, the list length decreases and subsequent creates produce IDs that collide with existing items. This makes duplicate-ID items inaccessible through PATCH/DELETE endpoints.

Root Cause

ID generation is tied to the current list length rather than a monotonically increasing counter. Any deletion reduces the length, causing the next ID to potentially match an existing item.

Reproduction

1. Create items A (id=1) and B (id=2)
2. Delete item A — list length becomes 1
3. Create item C — assigned id=2 (collision with B)

Recommended Fix

Replace the length-based approach with a module-level auto-incrementing counter. Update reset_items() to reset the counter for test isolation.

Proposed Test Case

def test_no_id_collision_after_delete(client):
    # Create two items
    resp1 = client.post("/items", json={"name": "A"})
    resp2 = client.post("/items", json={"name": "B"})
    id_b = resp2.get_json()["id"]

    # Delete first item
    client.delete(f"/items/{resp1.get_json()['id']}")

    # Create a new item — should NOT collide with B's id
    resp3 = client.post("/items", json={"name": "C"})
    id_c = resp3.get_json()["id"]
    assert id_c != id_b, "New item ID collides with existing item"

    # Verify all remaining items are accessible
    assert client.get(f"/items/{id_b}").status_code == 200
    assert client.get(f"/items/{id_c}").status_code == 200

---

Labels: This is a confirmed bug in existing functionality with clear reproduction steps.

[manish-jangra]

/fs-code