Store Put writes a task under a string key through a common Store interface. It replaces direct map assignment, so managers and workers can use the same operation whether tasks live in memory or in persistent storage. Its error result lets callers treat a failed write as an operational failure rather than assuming storage succeeded. section 11.2 section 11.5
The interface accepts interface{} so storage operations share one signature, but a task store expects a *task.Task. The in-memory implementation checks that type assertion before assigning the task to its map; an incompatible value returns an error. With an existing key, assignment overwrites the stored task and returns nil on success. section 11.3
A Put call follows a small, explicit path:
- Choose a stable string key, normally the task ID converted to a string. section 11.5
- Pass a pointer to task.Task to the Store implementation. section 11.3
- Check the returned error when failure must stop the surrounding operation, such as saving a queued task event before dispatch. section 11.5
- Call Put again after changing task state, timestamps, container ID, ports, or other persisted fields. section 11.5 section 11.6
Saving a state update
After retrieving and modifying a persisted task, save the replacement through the interface: m.TaskDb.Put(taskPersisted.ID.String(), taskPersisted) This preserves the manager’s dependency on Store rather than on a map. The worker uses the same pattern after a task starts, fails, stops, or completes. section 11.5 section 11.6
Put-first can simplify create-or-update behavior. A worker that cannot reliably distinguish a missing task from an underlying Get failure writes the queued task first; if Put succeeds, it then retrieves the task. The tradeoff is deliberate: an existing stored task is overwritten. section 11.6
Implementations keep the interface stable while changing the write mechanism. The in-memory store assigns a task pointer into a Go map. The persistent TaskStore opens a BoltDB read-write transaction, marshals the task to JSON bytes, and writes the key-value pair into a bucket; transaction, serialization, or bucket write errors propagate to the caller. section 11.3 section 11.9
Figure 11.2 Sequence diagram illustrating how the manager and worker save tasks to their respective datastores using the Put method
Trace how one task is stored first by the manager after POST /tasks and then by the worker after it receives the task. section 11.3
