Fix nil pointer dereference in kubernetesResolver.Stop() when k8smetadata extension is active

[musa-asad]

Summary

Fix a nil pointer dereference (SIGSEGV) panic in kubernetesResolver.Stop() that occurs during agent shutdown when the k8smetadata extension is configured.

Fixes #1743

Problem

When the k8smetadata extension is present in the agent configuration, the kubernetesResolver is initialized via a code path that does not allocate a safeStopCh (the extension manages its own lifecycle independently). However, Stop() unconditionally calls e.safeStopCh.Close(), causing a nil pointer dereference panic during shutdown.

The panic stack trace looks like:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x291a66f]

goroutine 1 [running]:
github.com/aws/amazon-cloudwatch-agent/plugins/processors/awsapplicationsignals/internal/resolver.(*kubernetesResolver).Stop(...)
    kubernetes.go:239

Fix

Add a nil check before calling Close() on safeStopCh. This matches the existing pattern already used in the k8smetadata extension's own Shutdown() method (extension/k8smetadata/extension.go).

Testing

Unit Tests

All existing tests pass, including TestEksResolver/Test_Stop:

$ go test ./plugins/processors/awsapplicationsignals/internal/resolver/ -v -count=1
=== RUN   TestEksResolver
=== RUN   TestEksResolver/Test_getWorkloadAndNamespaceByIP
=== RUN   TestEksResolver/Test_Stop
=== RUN   TestEksResolver/Test_Process_when_useListPod_is_true
=== RUN   TestEksResolver/Test_Process_when_useListPod_is_false
=== RUN   TestEksResolver/Test_extension_flag
--- PASS: TestEksResolver (0.00s)
PASS
ok  github.com/aws/amazon-cloudwatch-agent/plugins/processors/awsapplicationsignals/internal/resolver  0.062s

End-to-End Before/After EKS Verification

Tested on an EKS 1.30 cluster (2 managed nodes, t3.medium) with the CloudWatch Observability addon (v5.3.1-eksbuild.1), which enables the k8smetadata extension + Application Signals pipeline — the exact configuration that triggers the bug.

Both before and after confirmed k8smetadata extension active:

2026-04-30T05:03:28Z I! {"caller":"resolver/kubernetes.go:152","msg":"k8smetadata extension is present"}

Shutdown was triggered by sending SIGTERM to PID 1 inside the agent container via kubectl debug, which exercises the exact Stop() → safeStopCh.Close() code path.

BEFORE (unfixed 1.300066.0b1367) — panic on every shutdown:

2026-04-30T05:08:04Z I! {"caller":"otelcol@v0.124.0/collector.go:358","msg":"Received signal from OS","signal":"terminated"}
2026-04-30T05:08:04Z I! {"caller":"service@v0.124.0/service.go:331","msg":"Starting shutdown..."}
2026-04-30T05:08:04Z I! Profiler is stopped during shutdown
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x28f668f]

goroutine 1 [running]:
internal/sync.(*Mutex).Lock(...)
	internal/sync/mutex.go:63
sync.(*Mutex).Lock(...)
	sync/mutex.go:46
github.com/aws/amazon-cloudwatch-agent/internal/k8sCommon/k8sclient.(*SafeChannel).Close(0x0)
	.../kubernetes_utils.go:208 +0x2f
github.com/aws/amazon-cloudwatch-agent/plugins/processors/awsapplicationsignals/internal/resolver.(*kubernetesResolver).Stop(0x3?, {0x321b60bb18f8?, 0x321b60bb1860?})
	.../kubernetes.go:239 +0x1a

Container crashed and restarted (restart count: 1).

AFTER (this PR) — clean shutdown, 3/3 tests:

2026-04-30T05:10:18Z I! {"caller":"otelcol@v0.124.0/collector.go:358","msg":"Received signal from OS","signal":"terminated"}
2026-04-30T05:10:18Z I! {"caller":"service@v0.124.0/service.go:331","msg":"Starting shutdown..."}
2026-04-30T05:10:18Z I! Profiler is stopped during shutdown
2026-04-30T05:10:18Z I! {"caller":"extensions/extensions.go:69","msg":"Stopping extensions..."}
2026-04-30T05:10:18Z I! {"caller":"entitystore/extension.go:138","msg":"Pod to Service Environment Mapping TTL Cache stopped"}
2026-04-30T05:10:18Z I! {"caller":"service@v0.124.0/service.go:345","msg":"Shutdown complete."}

No panic, no SIGSEGV. Container restarted cleanly (restart count: 1, from SIGTERM — not a crash).

Test	Image	SIGTERM Result	Panic?
Before	1.300066.0b1367 (unfixed)	SIGSEGV crash	YES — kubernetes.go:239
After #1	This PR (e3addeb)	Shutdown complete.	NO
After #2	This PR (e3addeb)	Shutdown complete.	NO
After #3	This PR (e3addeb)	Shutdown complete.	NO