Update & Delete

TaskStore can already create tasks, fetch one by id, and list them all in a stable order. Two operations are still missing, and they're the ones every CRUD service needs to finish the set: changing a task and removing it. Update and Delete share a shape you've already half-written — Get already handles "does this id exist?" with a comma-ok map lookup — but here that check has to gate a write, not just a read.

Existence first, action second

Both methods open the same way: lock s.mu, then check whether id is in s.items before doing anything else.

if _, ok := s.items[id]; !ok {
	return Task{}, false // or just false, for Delete
}

This isn't defensive padding — it's the whole point of the method. A caller handing you an id has no way to know in advance whether that task still exists (maybe another goroutine deleted it a moment ago), so the store has to say so explicitly. Skip the check and Update would happily invent a task under an id nobody created; skip it in Delete and you can't tell a successful removal from a no-op.

Why bool, not silence

Both methods report success as a second (or only) return value instead of, say, silently doing nothing on a miss. That's not just tidiness — it's setting up the next chapter. Part 2 puts real HTTP handlers on top of this store, and a handler's whole job on PUT /tasks/{id} or DELETE /tasks/{id} is turning "task not found" into a 404 response. If Update and Delete swallowed the miss internally, the handler would have no signal to act on. The bool is the interface between store and handler — get it wrong here and every caller downstream has to work around it.

Update: replace, don't merge

Update takes a full replacement — title, done, and priority — and writes a brand new Task back into the map, keeping only the existing id:

t := Task{ID: id, Title: title, Done: done, Priority: priority}
s.items[id] = t

Notice what's not here: no reading the old task first, no field-by-field merging. This is a "put the whole resource back" update, matching the semantics of HTTP PUT — the caller sends the complete new state, and whatever they don't send is gone. A PATCH-style partial update, where a caller can change just done and leave title alone, needs a different signature (probably pointer or optional fields) — that's Part 2's problem, once there's a JSON request body to decide what "unset" means.

Delete: two structures, one operation

This is where the split between items and order — introduced last lesson purely to fix iteration order — has a second job: staying in sync. delete(s.items, id) removes the entry from the map, but order is a separate slice, and nothing about deleting a map key touches it. Forget the second step and the id keeps showing up in List output forever, pointing at a task that no longer exists — a comma-ok lookup in List would paper over the crash, but the deleted task would still leak into every listing.

The fix is a linear scan to find and splice out the id:

for i, oid := range s.order {
	if oid == id {
		s.order = append(s.order[:i], s.order[i+1:]...)
		break
	}
}

s.order[:i] is everything before the match, s.order[i+1:] everything after; appending the second onto the first closes the gap in place. The break matters too — ids are unique by construction (each comes from nextID), so there's never a second match to find, and continuing to scan would just be wasted work.

With Update and Delete in place, TaskStore supports every operation this book's service will expose: create, get, list, update, delete. Nothing about its method signatures needs to change even when Part 2 swaps in real HTTP handlers and JSON encoding — those methods, and their bools, are exactly what a handler will call.