[9.5](backport #7548) fix: handle index_not_found in token resolver to avoid spurious checkin errors

[mergify]

What is the problem this PR solves?

When .fleet-actions does not yet exist (e.g. a new project that has never had an explicit agent action), a fleet-server restart or a new fleet-server instance being spun up clears the in-memory LRU ack-token cache. The subsequent cache-miss triggers a search on .fleet-actions via TokenResolver.Resolve → dl.FindSeqNoByDocID. ErrIndexNotFound was not handled in this code path and propagated all the way up to the agent check-in handler, logging resolveSeqNo: elastic fail 404: index_not_found_exception: no such index [.fleet-actions] on every check-in.

How does this PR solve the problem?

Treats ErrIndexNotFound the same as ErrNotFound in TokenResolver.Resolve, so the caller (resolveSeqNo in handleCheckin.go) falls back to agent.ActionSeqNo gracefully. This is consistent with how every other read path in fleet-server already handles a missing .fleet-actions index (e.g. findActionsHits, DeleteExpiredForIndex).

How to test this PR locally

Start fleet-server against a cluster where .fleet-actions does not exist, enroll an agent, and verify check-ins succeed without resolveSeqNo errors in the logs.

Design Checklist

• I have ensured my design is stateless and will work when multiple fleet-server instances are behind a load balancer.
• I have or intend to scale test my changes, ensuring it will work reliably with 100K+ agents connected.
• I have included fail safe mechanisms to limit the load on fleet-server: rate limiting, circuit breakers, caching, load shedding, etc.

Checklist

• 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

🤖 Generated with Claude Code

---

This is an automatic backport of pull request #7548 done by Mergify.

[github-actions]

TL;DR

The failing Buildkite step (Run unit tests: MacOS 13) exited with go test ... ./... status 1, but the provided log excerpt is truncated and does not include the actual failing package/test output. From this branch/commit, the changed code in this PR passes race-enabled tests, so this currently looks like a non-code or transient CI failure until full failing lines are available.

Remediation

• Retry the failed Buildkite step once to rule out a transient MacOS runner failure.
• If it fails again, capture and attach the full step log (including the first failing --- FAIL: or FAIL\t<package> line) and re-run go test -tags=grpcnotrace -v -race -coverprofile=build/coverage-darwin.out ./... on MacOS for the exact failing package.

Investigation details

Root Cause

The pre-fetched log at /tmp/gh-aw/buildkite-logs/fleet-server-smartbear-testexecute-run-unit-tests-macos-13.txt only contains trailing output and ends with a generic harness failure:

• FAIL
• Error: running "go test -tags=grpcnotrace -v -race -coverprofile=build/coverage-darwin.out ./..." failed with exit code 1

It does not include the specific failing test/package line, so a concrete code-level root cause cannot be proven from the available Buildkite evidence.

I also checked the PR delta (backport of #7548):

• internal/pkg/action/token_resolver.go (new ErrIndexNotFound handling in Resolve, around the newly added branch near line 51 in diff)
• internal/pkg/action/token_resolver_test.go (new tests)

These changes are narrow and local to token resolution behavior, and do not overlap with any visible failing output in the provided CI excerpt.

Evidence

• Build: https://buildkite.com/elastic/fleet-server/builds/16090
• Job/step: Run unit tests: MacOS 13
• Key log excerpt:
  • FAIL
  • Error: running "go test -tags=grpcnotrace -v -race -coverprofile=build/coverage-darwin.out ./..." failed with exit code 1

Verification

• Re-ran PR-local race tests for changed area: go test -tags=grpcnotrace -race ./internal/pkg/action -run TestTokenResolverResolve -v (passes).
• Re-ran repo-wide race tests in this environment: go test -tags=grpcnotrace -race ./... (passes).

Follow-up

• No matching open flaky-test issue was found in elastic/fleet-server for this MacOS unit-test step signature. If the retry fails with the same concrete test/package, opening a flaky-test issue with the exact failing line would help tracking.

---

What is this? | From workflow: PR Buildkite Detective

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