Personal Catalogue: React, Express & MongoDB — Chapter 5, Exercise 2
=====================================================================

TASK
Reproduce the lost-update scenario using two real sequential requests
both built from the same original tags snapshot, sent through the
naive PUT approach -- then repeat the same two-request scenario using
$addToSet instead, and compare the two final results.

SOLUTION

Starting state, a real Book with tags: ["Python", "Programming"].

PART A -- the naive PUT approach:

  # Both "tabs" read the same original snapshot first:
  curl http://localhost:4000/api/items/<id>
  # → tags: ["Python", "Programming"]   (captured by both "Tab A" and "Tab B")

  # "Tab A" adds Web Development to its own copy of the snapshot, then PUTs
  # the whole array back:
  curl -X PUT http://localhost:4000/api/items/<id> \
    -H "Content-Type: application/json" \
    -d '{"tags":["Python","Programming","Web Development"]}'

  # "Tab B", still holding its own original snapshot from before Tab A's
  # change, adds FastAPI to THAT copy and PUTs its own full array back:
  curl -X PUT http://localhost:4000/api/items/<id> \
    -H "Content-Type: application/json" \
    -d '{"tags":["Python","Programming","FastAPI"]}'

  curl http://localhost:4000/api/items/<id>

Result A:
  tags: ["Python", "Programming", "FastAPI"]

Web Development is genuinely gone. Tab B's PUT overwrote the entire
array with what it believed to be the full, correct set -- it never
knew Tab A's edit had happened.

PART B -- the same scenario, using $addToSet instead:

Reset the book back to tags: ["Python", "Programming"], then:

  curl -X PATCH http://localhost:4000/api/items/<id>/tags/add \
    -H "Content-Type: application/json" -d '{"tag":"Web Development"}'

  curl -X PATCH http://localhost:4000/api/items/<id>/tags/add \
    -H "Content-Type: application/json" -d '{"tag":"FastAPI"}'

  curl http://localhost:4000/api/items/<id>

Result B:
  tags: ["Python", "Programming", "Web Development", "FastAPI"]

Both additions survive.

WHY THE RESULTS DIFFER
------------------------
In Part A, each PUT request carries a complete replacement array decided
entirely by the client, based on a snapshot that could already be stale
by the time the request arrives. MongoDB has no way to know that
"Tab B's" request is based on outdated information -- it just replaces
the array with exactly what it was told, discarding whatever changed in
between.

In Part B, neither PATCH request ever mentions the full array at all.
Each one only says "make sure this one value is present," and MongoDB
resolves that instruction against whatever the document's tags array
actually contains at the exact moment the operation runs on the server
-- not whatever a client remembered from earlier. Two updates issued in
either order produce the same correct union of tags, because neither
one ever had the power to overwrite what the other had already done.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reproduces the exact lost-update failure described in the chapter
with real, sequential requests and a real final result showing data
loss, then reruns the identical two-edit scenario through the atomic
routes and shows a genuinely different, correct outcome -- demonstrating
the difference in results rather than only asserting that one approach
is safer.