Add solution for Challenge 30 by t4e1

[t4e1]

No description provided.

[coderabbitai]

Walkthrough

A ContextManager interface and simpleContextManager implementation are introduced in a Go solution file. The interface provides methods for creating cancellable and timeout-enabled contexts, managing context values, executing cancellable tasks, and waiting for completion. Helper functions demonstrate context-aware work simulation and batch processing with cancellation checks.

Changes

Cohort / File(s)	Change Summary
ContextManager abstraction and implementation challenge-30/submissions/t4e1/solution-template.go	Added ContextManager interface with 6 methods (CreateCancellableContext, CreateTimeoutContext, AddValue, GetValue, ExecuteWithContext, WaitForCompletion); introduced simpleContextManager struct implementation; added NewContextManager constructor; added SimulateWork, ProcessItems helper functions; added main function with basic usage example

Sequence Diagram(s)

sequenceDiagram
    participant main
    participant ctx as ContextManager
    participant goroutine as Task Goroutine
    participant done as Done Channel

    main->>ctx: ExecuteWithContext(ctx, task)
    activate ctx
    ctx->>goroutine: go task()
    activate goroutine
    
    par Task Execution
        goroutine->>goroutine: Execute task()
        goroutine->>done: send result/error
    and Cancellation Watch
        ctx->>ctx: select on ctx.Done()
    end
    
    alt Task completes first
        done->>ctx: receive result
        ctx->>main: return task error
    else Context cancelled first
        ctx->>ctx: ctx.Done() signals
        ctx->>main: return context.Cancelled
    end
    deactivate goroutine
    deactivate ctx

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20–25 minutes

• Interface design: Verify that the ContextManager abstraction is well-suited and follows Go idioms
• Goroutine and channel patterns: Review ExecuteWithContext implementation for proper channel handling, race conditions, and goroutine cleanup
• Error handling: Check consistency of error returns across all methods and proper context cancellation propagation
• Context value usage: Verify AddValue/GetValue implementations and type assertion safety

Possibly related PRs

• Add solution for Challenge 27 #55: Adds identical ContextManager interface and simpleContextManager implementation with the same methods and helper functions in challenge-30
• Add solution for Challenge 30 by nzamulov #629: Adds the same ContextManager interface, simpleContextManager implementation, and helper functions (SimulateWork, ProcessItems) with overlapping method signatures

Pre-merge checks

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description Check	❓ Inconclusive	No pull request description was provided by the author. The check criteria require the description to be related to the changeset to pass, vague or generic to be inconclusive, or completely unrelated to fail. Since no description exists at all, it cannot be evaluated against these criteria designed for evaluating existing descriptions. The absence of a description makes it impossible to determine whether it meets the "related in some way" standard for passing.	Consider adding a brief description explaining the solution approach or key aspects of the ContextManager implementation. Even a minimal description relating to the changeset would clarify the intent and help reviewers understand the submission.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The pull request title "Add solution for Challenge 30 by t4e1" directly and accurately describes the main change in the changeset. The file path challenge-30/submissions/t4e1/solution-template.go confirms this is indeed a solution submission for Challenge 30. The title is specific, clear, and concise — it immediately communicates the primary purpose of the change without unnecessary noise or vagueness.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (8)

challenge-30/submissions/t4e1/solution-template.go (8)

94-104: Avoid timer leaks; prefer time.NewTimer + Stop over time.After in libraries

Using time.After allocates a timer that can leak if used repeatedly. NewTimer with Stop is safer.

 func (cm *simpleContextManager) WaitForCompletion(ctx context.Context, duration time.Duration) error {
-  select {
-  case <-ctx.Done():
-    return ctx.Err()
-  case <-time.After(duration):
-    return nil
-  }
+  timer := time.NewTimer(duration)
+  defer func() {
+    if !timer.Stop() {
+      <-timer.C
+    }
+  }()
+  select {
+  case <-ctx.Done():
+    return ctx.Err()
+  case <-timer.C:
+    return nil
+  }
 }

 func SimulateWork(ctx context.Context, workDuration time.Duration, description string) error {
-  select {
-  case <-ctx.Done():
-    return ctx.Err()
-  case <-time.After(workDuration):
-    fmt.Println(description)
-    return nil
-  }
+  timer := time.NewTimer(workDuration)
+  defer func() {
+    if !timer.Stop() {
+      <-timer.C
+    }
+  }()
+  select {
+  case <-ctx.Done():
+    return ctx.Err()
+  case <-timer.C:
+    fmt.Println(description)
+    return nil
+  }
 }

Also applies to: 107-118

---

127-138: Make per-item delay cancellable during sleep

Sleeping ignores mid-sleep cancellations. Use a timer and select to exit promptly.

-    time.Sleep(50 * time.Millisecond)
+    timer := time.NewTimer(50 * time.Millisecond)
+    select {
+    case <-ctx.Done():
+      if !timer.Stop() {
+        <-timer.C
+      }
+      return result, ctx.Err()
+    case <-timer.C:
+    }

---

55-60: Prefer typed context keys over strings to avoid collisions

Using string keys risks collisions across packages. Define a private key type and use it in main.

// add near the top (outside selected range)
type ctxKey string

const (
  keyUser      ctxKey = "user"
  keyRequestID ctxKey = "requestID"
)

-ctx = cm.AddValue(ctx, "user", "alice")
-ctx = cm.AddValue(ctx, "requestID", "12345")
+ctx = cm.AddValue(ctx, keyUser, "alice")
+ctx = cm.AddValue(ctx, keyRequestID, "12345")

Also applies to: 156-158

---

63-71: Clarify GetValue semantics for nil values

ctx.Value returns nil both for “not set” and “set to nil”. Your boolean treats nil as “not found”. Either document this explicitly or wrap stored values to disambiguate.

Would you like me to draft a tiny wrapper type (e.g., struct{ present bool; v any }) to preserve presence?

---

14-16: Document cancel requirement for timeout contexts

Callers must invoke the returned cancel func from WithTimeout to release resources.

- // Create a context with timeout
+ // Create a context with timeout.
+ // The returned CancelFunc MUST be called to release resources, per context.WithTimeout docs.
   CreateTimeoutContext(parent context.Context, timeout time.Duration) (context.Context, context.CancelFunc)

Also applies to: 47-52

---

40-41: Remove stale TODO/Hints now that implementations exist

They add noise and can confuse future readers. Convert to concise doc comments or delete.

Happy to sweep and submit a cleanup patch.

Also applies to: 48-50, 56-58, 64-67, 75-78, 95-98, 108-111, 122-125

---

1-161: Optional: library vs. main

This looks like a reusable utility. Consider moving types to package contextutil (or similar) and keeping main only for examples.

If desired, I can split the file and add a small example under cmd/.

---

1-161: Remove obsolete TODO/Hint comments and refactor string-literal context keys

The code is complete but retains TODO and Hint comments that are now misleading (lines 40–41, 48–49, 56–57, 64–65, 75–76, 95–96, 108–109, 122). Remove them.

Additionally, the main() function uses untyped string literals as context keys ("user", "requestID" at lines 155–156), which violates Go best practices and risks key collisions across packages. Define typed constant keys instead:

type contextKey string
const (
	userKey      contextKey = "user"
	requestIDKey contextKey = "requestID"
)

Then update the calls to use cm.AddValue(ctx, userKey, "alice") and cm.AddValue(ctx, requestIDKey, "12345").

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2af88d2 and a06f8a6.

⛔ Files ignored due to path filters (2)

• badges/PolinaSvet.svg is excluded by !**/*.svg
• badges/malakagl.svg is excluded by !**/*.svg

📒 Files selected for processing (1)

• challenge-30/submissions/t4e1/solution-template.go (1 hunks)

🔇 Additional comments (1)

challenge-30/submissions/t4e1/solution-template.go (1)

38-44: LGTM: cancellable context implementation is correct

Uses context.WithCancel as expected.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Make tasks cancellable; pass ctx into the task to prevent goroutine leaks

Current design can’t stop a long-running task; the goroutine keeps executing after ctx is done. Pass ctx to the task and propagate cancellation.

- // Execute a task with context cancellation support
- ExecuteWithContext(ctx context.Context, task func() error) error
+ // Execute a task; task must observe ctx for cancellation.
+ ExecuteWithContext(ctx context.Context, task func(context.Context) error) error

-func (cm *simpleContextManager) ExecuteWithContext(ctx context.Context, task func() error) error {
+func (cm *simpleContextManager) ExecuteWithContext(ctx context.Context, task func(context.Context) error) error {
   errCh := make(chan error, 1)
   go func() {
-    errCh <- task()
+    errCh <- task(ctx)
   }()
   select {
   case err := <-errCh:
     return err
   case <-ctx.Done():
     return ctx.Err()
   }
 }

Also applies to: 74-91

🤖 Prompt for AI Agents

In challenge-30/submissions/t4e1/solution-template.go around lines 24 and 74-91,
the task function currently has signature func() error so long-running tasks
cannot be cancelled and goroutines leak after ctx is done; change
ExecuteWithContext to accept task func(ctx context.Context) error, update all
internal goroutine launches to pass the same ctx, and modify the select/err
propagation so the goroutine returns promptly when ctx.Done() is closed (i.e.,
check ctx in the task or select inside the worker and return a
canceled/appropriate error), and update every call site within lines 74-91 to
pass ctx into the task closures and propagate the returned error back to caller.