Personal Catalogue: React, Express & MongoDB — Chapter 5, Exercise 3 ===================================================================== TASK Send a PATCH .../tags/add request against a real Dvd's or Cd's own _id and explain why it returns a 404 even though that _id definitely exists in the items collection. SOLUTION First, confirm the id genuinely exists: curl http://localhost:4000/api/items/ Output: a real 200 response with the full Cd document -- title, artist, itemType: "Cd", and so on. The id is real and present in the database. Now send the tag request against that same id: curl -X PATCH http://localhost:4000/api/items//tags/add \ -H "Content-Type: application/json" \ -d '{"tag":"Anything"}' Output: 404 {"error":"Item not found"} WHY THIS HAPPENS ----------------- The tags/add route calls Book.findByIdAndUpdate(req.params.id, ...) -- not Item.findByIdAndUpdate(). Book is a Mongoose discriminator model, and querying through a discriminator model automatically adds a filter on the discriminator key behind the scenes, equivalent to also requiring itemType: "Book" on every query issued through it. This is the exact same behavior Chapter 2 already described for reads ("querying through a specific discriminator model like Book filters automatically to just that type") -- this exercise confirms it applies to writes too. Because the real document at this id has itemType: "Cd", it never matches Book's own automatic filter, no matter what its _id is. Book.findByIdAndUpdate() behaves exactly as if no document with that id existed at all from Book's own point of view, returns null, and the route's own `if (!updated)` check correctly reports it as "Item not found" -- a genuinely accurate description of what Book itself sees, even though the wider items collection, and the plain Item model, both know the document is really there. WHY THIS WORKS AS AN ANSWER ---------------------------- It first proves the id is real by fetching it successfully through the base Item model, then shows the same id genuinely fails through Book specifically, and explains the real, documented discriminator mechanism responsible -- an automatic itemType filter applied to every query issued through a discriminator model -- rather than treating the 404 as a bug or an unexplained inconsistency.