💡 Improvement: Handle `issueId=0` gracefully when `issueKey` is provided in `get_issue`

[hdesoer]

Background

When using the get_issue tool via MCP/LLM clients, the request may sometimes include both fields like:

{
  "issueId": 0,
  "issueKey": "PROJ-123"
}

This can happen because some clients or LLMs automatically populate missing numeric fields with 0.

---

Example

Below is an actual case where the tool was invoked with both issueId=0 and a valid issueKey:

As shown above:

• issueKey is correctly provided
• but issueId is automatically set to 0

---

Current Behavior

In this case, issueId is used even when it is 0, resulting in:

backlog.getIssue(0) // → 404 Not Found

The provided issueKey is not used.

---

Suggestion

It might be safer to treat non-positive issueId values (e.g. 0) as invalid, and fall back to issueKey when available.

For example:

if (typeof issueId === 'number' && issueId > 0) {
  return backlog.getIssue(issueId);
}

if (issueKey) {
  return backlog.getIssue(issueKey);
}

---

Why This Could Help

Even after splitting issueId and issueKey (since v0.2.0),
LLM-based clients may still:

• include both fields
• use 0 as a default placeholder for numbers

Handling this case defensively could improve robustness when used with MCP / AI integrations.

---

Optional Enhancements

• Restrict issueId to positive integers in schema (.positive())
• Clarify in the description that issueId should not be set unless known

---

Summary

• Scenario: issueId=0 + valid issueKey
• Current: issueId is used → 404
• Suggested: ignore invalid issueId and fallback to issueKey

---

Thanks for considering 🙌