Runtime & concurrency
Reveal answer and reasoning
Let a successful TryDequeue or another documented transfer operation establish ownership, rather than a prior Count or TryPeek. Record which items were actually claimed, then define processing, cancellation, retry, and failure outcomes explicitly. If the product needs durable acknowledgment, choose a real storage or messaging protocol instead of assigning that meaning to an in-memory concurrent collection.
Test bounded consumers with unique prepared items, controlled competing observations, and direct checks for duplicate ownership or lost handling under the supported failure model. Keep worker scheduling out of fixed expected assignments unless the test deliberately controls it. The wrong design checks nonempty, assumes the next remove cannot fail, and silently drops an item when later processing throws. FIFO storage does not provide consumer fairness or automatically reinsert failed work, and a process-local queue cannot establish delivery across a restart.
What a strong answer covers
- Use the actual transfer result for ownership.
- Specify processing and retry semantics separately.
- Test unique ownership without guessing worker order.
Common pitfall
Extending queue operation thread safety into durable processing or automatic retry guarantees.
Follow-up questions
- When would a channel be a better lifecycle abstraction?
- How would a durable broker's acknowledgment change the design?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.