Run Service renewal throws NullReferenceException after a post-success failure and abandons the active job

[siahuat0727]

Describe the bug

For Run Service jobs, if lease renewal succeeds at least once and a later renewal throws a non-terminal exception, the renewal task can fail with NullReferenceException. The active worker is then cancelled and the job is reported as Abandoned, even though the most recently acquired lease is still valid.

In the Run Service overload of RenewJobRequestAsync, request is initialized to null and never assigned:

TaskAgentJobRequest request = null;

var renewResponse = await runServer.RenewJobAsync(planId, jobId, token);

After the first successful renewal, the exception path reads:

remainingTime = request.LockedUntil.Value + TimeSpan.FromMinutes(5) - DateTime.UtcNow;

The successful response is stored in renewResponse, but the retry path reads request.LockedUntil. Therefore, a generic renewal exception after the first success causes a NullReferenceException.

Relevant source:

• https://github.com/actions/runner/blob/v2.336.0/src/Runner.Listener/JobDispatcher.cs#L748-L850
• https://github.com/actions/runner/blob/main/src/Runner.Listener/JobDispatcher.cs#L748-L850

The same implementation is present in v2.336.0 and in main as of 2026-08-14.

To Reproduce

This can be reproduced at unit level:

1. Configure IRunServer.RenewJobAsync to return a successful RenewJobResponse with a future LockedUntil.
2. Allow the next renewal cycle to start.
3. Configure the next call to throw HttpRequestException or another generic exception.
4. Observe that RenewJobRequestAsync throws NullReferenceException instead of entering the lease-window retry path.
5. The completed/faulted renewal task causes RunAsync to cancel the worker and report the job as Abandoned.

Expected behavior

After a successful renewal, a later retriable exception should use the most recent LockedUntil value and continue retrying within the existing lease window, including the configured five-minute buffer. The active worker should not be cancelled while that retry window remains valid.

Runner Version and Platform

• Runner version: 2.336.0
• Platform: Linux x64
• Environment: self-hosted runner in a Kubernetes Pod

What's not working?

The issue was observed twice on the same runner during a period of TLS/network instability.

First occurrence:

[2026-08-14 05:23:22Z] Successfully renew job <job-id>,
    job is valid till 08/14/2026 05:33:22

[2026-08-14 05:26:45Z] Back off ... before next retry. 1 attempt left.

[2026-08-14 05:26:55Z] Catch exception during renew runner job <job-id>.
System.Net.Http.HttpRequestException: The SSL connection could not be established.
System.IO.IOException: Received an unexpected EOF or 0 bytes from the transport stream.

[2026-08-14 05:26:55Z] Send job cancellation message to worker for job <job-id>.
[2026-08-14 05:29:31Z] Job completed with result: Abandoned
[2026-08-14 05:29:37Z] System.NullReferenceException:
    Object reference not set to an instance of an object.
    at GitHub.Runner.Listener.JobDispatcher.RenewJobRequestAsync(IRunServer runServer, ...)

The RunServer request layer made five total attempts—one initial attempt and four retries—before the exception reached JobDispatcher.

A second job showed the same sequence:

05:51:45  Last successful renewal; valid until 06:01:45
05:55:27  Renewal exception and immediate worker cancellation
06:00:26  Job reported as Abandoned
06:08:48  NullReferenceException surfaced

The delayed NullReferenceException is surfaced when the already-faulted renewal task is later awaited; worker cancellation begins as soon as that task becomes completed.

Job Log Output

The active workflow step was cancelled without a workflow cancellation request.

Runner and Worker's Diagnostic Logs

The worker received the cancellation at the same time as the renewal failure:

[2026-08-14 05:26:55Z] Cancellation/Shutdown message received.
[2026-08-14 05:26:55Z] Cancel current running step.
[2026-08-14 05:26:55Z] Sending SIGINT to process <pid>.
[2026-08-14 05:27:03Z] Sending SIGTERM to process <pid>.
[2026-08-14 05:27:05Z] Kill entire process tree since both cancel and terminate signal have been ignored.

Full diagnostic logs contain environment-specific information and can be provided privately if needed.

Possible fix direction

One option would be to retain the most recent renewResponse.LockedUntil value and use it in the exception path instead of reading the unassigned request.

A regression test could cover the Run Service sequence:

successful renewal -> generic exception -> retry/recovery

The existing Run Service test covers the terminal TaskOrchestrationJobNotFoundException case, but not a generic exception after a successful renewal:

https://github.com/actions/runner/blob/main/src/Test/L0/Listener/JobDispatcherL0.cs#L219-L285

The affected Run Service renewal overload was introduced in #2461.