fix: BaseTask.get_id potentially returning None

[Copilot]

BaseTask.get_id() silently returned None when no matching task was found in the workflow state, causing an obscure TypeError downstream in get_idx() when attempting to subscript the None result.

Context

get_id() iterated over workflow state without a fallback, returning None on a miss. Callers like get_idx() assumed a str return, producing:

TypeError: 'NoneType' object is not subscriptable

Change Summary

• Added raise RuntimeError(...) at the end of BaseTask.get_id() to surface the failure at the source with a clear, actionable message including the task name:

  raise RuntimeError(
      f"Task ID not found for task '{self.name()}'. "
      "This may indicate the task was not properly initialized."
  )

Rationale

Failing fast with a descriptive error is preferable to propagating None and producing a confusing TypeError several call frames away. Including the task name in the message aids debugging without requiring a stack trace inspection.

Impact

Any code path that reaches get_id() with a task not present in the workflow state will now raise RuntimeError immediately instead of silently returning None. The return type contract (str) is now enforced at runtime.

[Copilot]

Pull request overview

This PR prevents BaseTask.get_id() from implicitly returning None when the workflow state cannot be matched to the current task, avoiding downstream TypeErrors and making the failure explicit.

Changes:

• Add a terminal RuntimeError in BaseTask.get_id() when no task ID can be resolved from the workflow state.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The new RuntimeError message ('Task ID not found, should be unreachable') is likely to surface in real user scenarios (e.g., partially initialized workflow) and isn’t actionable. Consider including the task name (and possibly the expected key prefix 'TaskObject:' / hint about initialization) so users can diagnose which task failed and why.

[Copilot]

This change introduces a new failure mode (raising when the task ID can’t be resolved) but there’s no test asserting the exception behavior. Adding a focused unit test that constructs a BaseTask with a stubbed/empty workflow state and verifies RuntimeError would prevent regressions and clarify the intended contract.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}

[Gobot1234]

I don't think this really needs a test as it's covered by type checking