[Bug] adk_stale_agent counts failed issue runs as successfully processed and exits 0

[kerem-turhan]

🔴 Required Information

Describe the Bug:

In contributing/samples/adk_team/adk_stale_agent/main.py,
process_single_issue() catches any exception from the runner and returns its
normal (duration, api_calls) tuple. The batch then increments
processed_count by len(chunk), independent of whether those calls reached a
decision.

As a result, a run in which every issue raises can still log
Successfully processed 3 issues. and finish with exit code 0. This is an
outcome-accounting issue in this maintenance sample, not a claim about model
quality or the ADK package as a whole.

The adjacent
contributing/samples/adk_team/adk_issue_monitoring_agent/main.py has the same
per-issue catch-and-normal-return shape. I am keeping the requested change
scoped to the stale-agent file.

Steps to Reproduce:

1. Check out google/adk-python at
   20842eb8e035a6e128b7585ca81f4625e00147c2.
2. Set PYTHONPATH=contributing/samples/adk_team.
3. Import adk_stale_agent.main, replace InMemoryRunner with the
   deterministic fake below, and replace get_old_open_issue_numbers with a
   function returning [101, 202, 303].
4. Run asyncio.run(main.main()) and inspect the logs and process status.

import asyncio
from types import SimpleNamespace
from adk_stale_agent import main

class FailingRunner:
  def __init__(self, **kwargs):
    self.session_service = self

  async def create_session(self, **kwargs):
    return SimpleNamespace(id="synthetic-session")

  async def run_async(self, **kwargs):
    if False:
      yield None
    raise RuntimeError("synthetic runner failure")

main.InMemoryRunner = FailingRunner
main.get_old_open_issue_numbers = lambda *args, **kwargs: [101, 202, 303]
main.get_api_call_count = lambda: 0
main.reset_api_call_count = lambda: None
asyncio.run(main.main())

This fake replaces only the runner/issue-discovery boundaries; no API key or
network call is needed for the behavior under test.

Expected Behavior:

The summary should distinguish succeeded and failed issues, and the command
should return a non-zero status when one or more issue audits fail. One issue
failure may still be isolated so the rest of the batch can run.

Observed Behavior:

ERROR Error processing issue #101: synthetic runner failure
ERROR Error processing issue #202: synthetic runner failure
ERROR Error processing issue #303: synthetic runner failure
INFO Successfully processed 3 issues.

The process exits 0.

Environment Details:

• ADK Library Version: source tree reports 2.5.0; sample frozen at commit
  20842eb8e035a6e128b7585ca81f4625e00147c2
• Desktop OS: macOS 26.5.2
• Python Version: 3.11.5

Model Information:

• Are you using LiteLLM: No
• Which model is being used: N/A; the runner boundary is a deterministic fake
  and no model request is made

---

🟡 Optional Information

Regression:

Not determined.

Logs:

The relevant output is included above. The reproduction emits one traceback
per injected issue and then the success summary.

Additional Context:

At the frozen commit, .github/workflows/issue-maintenance.yml runs this
module daily and grants the job issues: write. This report does not claim
that a production run has encountered the injected failure or estimate its
frequency.

A single-file remediation in adk_stale_agent/main.py could:

1. return a success flag with each task's metrics;
2. increment processed_count only for successful results and list failures
   separately;
3. after all chunks finish, raise if any issue failed; and
4. let that final exception propagate from the __main__ handler so the
   workflow receives a non-zero exit status.

That preserves per-issue isolation while making the batch outcome observable.

Minimal Reproduction Code:

Included in Steps to Reproduce.

How often has this issue occurred?:

• Always (100%) in the deterministic reproduction

[surajksharma07]

@kerem-turhan Hit the exact same thing: process_single_issue() swallows the failure and still counts it as a success.

PR #6521 looks like it fixes this — tested it against your repro steps and it worked on my end.

Could you give it a try and confirm it holds up before it moves toward merge?

[kerem-turhan]

Confirmed on the current PR head dad579e93f9009d805d24e865b63e70c015514b2 against the same deterministic repro from this issue.

• All 3 injected runner failures: Progress: 3/3 (completed attempts), Successfully processed 0 issues., Failed to process 3 issues: [101, 202, 303], exit 1.
• Positive control, all 3 succeed: Successfully processed 3 issues., exit 0.
• Mixed result, only issue 202 fails: Successfully processed 2 issues., Failed to process 1 issues: [202], exit 1.

The PR’s focused test file also passes: 2 tests.

One detail in the current revision: expected per-issue failures no longer surface as an unexpected fatal exception. main() reports the batch outcome and __main__ maps a failed batch to exit 1.

Same scope caveat as the report: issue discovery and runner behavior are deterministic fakes, so this verifies batch accounting and process exit status, not agent quality or production frequency. Environment: macOS, Python 3.11.5.

Holds up on my end — thanks for the quick fix.