Get retrieves one stored task by its string key through the Store interface. Its signature returns interface{} and error, allowing managers and workers to use the same operation whether storage is an in-memory map or a persistent datastore. A successful call yields the stored task; a missing key is reported as an error rather than as an indistinguishable empty result. section 11.2 section 11.3
The basic lookup is deliberately small: read the map with Go’s comma-ok idiom, return the task when ok is true, and otherwise return nil with an error naming the absent key. Callers must handle both the retrieval error and the concrete type hidden by interface{} before using task fields. section 11.3 section 11.5
Checking a persisted task before updating it
When the manager receives a worker-reported task, it calls TaskDb.Get with the task ID string. On an error, it logs the failure and continues to the next task. On success, it asserts the result to *task.Task, then updates fields on that persisted task and stores it again with Put. This replaces direct map access with the Store contract. section 11.5
Get affects control flow where absence and storage failure need different treatment. A worker that previously looked up a task and created it when absent instead writes with Put first, then calls Get. This tradeoff avoids treating every Get error as evidence that the task does not exist. section 11.6
Listing 11.5 The Get method
func (i *InMemoryTaskStore) Get(key string) (interface{}, error) {
t, ok := i.Db[key]
if !ok {
return nil, fmt.Errorf("task with key %s does not exist", key)
}
return t, nil
}
The in-memory implementation shows the complete lookup path: map access, absence check, descriptive error, and successful return. section 11.3
A persistent task store keeps the same interface while changing the mechanics. Get opens a read-only BoltDB transaction, selects the bucket, retrieves bytes by key, rejects a nil value as not found, unmarshals JSON into task.Task, and returns a pointer. Persistent event retrieval follows the same pattern for task events. section 11.9 section 11.10
