Give service-runtime components more time to check in before failing an upgrade

[macdewee]

What does this PR do?

Changes when a service-managed component (like Elastic Defend) gets marked as failed after it stops checking in. Before, any service component that missed check-ins for about 90 seconds was marked failed, no matter what. Now, the failure point is based on how long that component's own install/uninstall/check operations are allowed to take. For Elastic Defend that is 600 seconds, so it now gets up to 10 minutes instead of 90 seconds before being marked failed. If no such timeout is configured, the old 90 second behavior stays the same. The component still shows as degraded right away, so this is only about delaying the failed state, not hiding problems.

Why is it important?

Elastic Defend sometimes takes longer than 90 seconds to fully restart after an Agent upgrade, even when nothing is wrong. Agent was treating that normal slow restart as a broken upgrade and automatically rolling it back. This caused unnecessary rollbacks, and customers were working around it by removing Defend before upgrading and re-adding it afterward.

Checklist

• I have read and understood the pull request guidelines of this project.
• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in ./changelog/fragments using the changelog tool
• I have added an integration test or an E2E test

Disruptive User Impact

None expected. Service-managed components (currently only Elastic Defend) get more time before being marked failed, but only up to their own configured operation timeouts. Components that are genuinely stuck still end up failed, just later.

How to test this PR locally

Run go test ./pkg/component/runtime/... -run TestServiceCheck -v to see the new unit tests covering: a normal check-in staying healthy, a slow-but-within-timeout check-in staying degraded instead of failed, a genuinely stuck component still ending up failed, and a component with no configured timeout keeping the old 90 second behavior.

Related issues

• Relates elastic/ingest-dev#6395
• Relates elastic/sdh-beats#6510
• Relates elastic/sdh-beats#7341

[mergify]

This pull request does not have a backport label. Could you fix it @macdewee? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-./d./d is the label that automatically backports to the 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[github-actions]

TL;DR

The golangci-lint workflow failed only on lint (windows-latest, default) because Go could not download gonum.org/v1/gonum@v0.17.0 from proxy.golang.org while typechecking. This does not point to a PR lint violation; rerun the failed job first.

Remediation

• Rerun the failed lint (windows-latest, default) job or the full golangci-lint workflow.
• If it fails again with the same dependency download error, treat it as a CI/network cache issue and retry after the module proxy is reachable; no code change is indicated by this log.

Investigation details

Root Cause

golangci-lint exited during typechecking after the Windows runner failed to read the gonum.org/v1/gonum module zip from proxy.golang.org. The other lint matrix jobs succeeded, including Windows with the define build tags, so the failure is isolated to dependency fetching in this job.

Evidence

• Workflow: https://github.com/elastic/elastic-agent/actions/runs/28955035159
• Job/step: lint (windows-latest, default) / golangci-lint
• Key log excerpt:

pkg\testing\tools\slope.go:10:2: could not import github.com/sajari/regression
... could not import gonum.org/v1/gonum/mat
... gonum.org/v1/gonum@v0.17.0: read "https://proxy.golang.org/gonum.org/v1/gonum/`@v/v0.17.0.zip`": stream error: stream ID 739; INTERNAL_ERROR; received from peer
##[error]golangci-lint exit with code 7

Validation

• Not run locally; this investigation used the failed Actions job log. The log shows a module proxy read error, not a reproducible source lint diagnostic.

Follow-up

• No previous PR Actions Detective comment was present on PR #15423, so this is not a duplicate report.

---

What is this? | From workflow: PR Actions Detective

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[infra-vault-gh-plugin-prod]

💚 Build Succeeded

• Buildkite Build
• Commit: 68a1cf3

cc @macdewee