fix: emit the alert check metric immediately on Start

[joshiste]

Summary

• Start() was a no-op, so the first alert metric only appeared after the first Status() poll (one CallInterval, i.e. 1s, after the check started).
• Start() now reuses the same status-check logic as Status(), so the first metric is emitted immediately when the check starts.
• Updated TestAlertCheckAction_Start_NoError to construct the action with a mock client instead of nil, since Start() now actually calls the Splunk client (previously safe as a pure no-op).

Test plan

• go build ./...
• go test ./extalert/...

[claude]

Claude finished @joshiste's task in 2m 13s —— View job

---

Claude finished reviewing

• Check for previously unresolved Claude review threads (none found)
• Gather context (diff, changed files)
• Review new changes for bugs, security, performance, concurrency issues
• Post final review

Review

The change looks correct and well-targeted.

• Start() in extalert/check.go:224-235 now delegates to the shared checkFiredAlerts helper and maps the returned StatusResult fields (Artifacts, Error, Messages, Metrics) onto StartResult. The error-path handling (if statusResult == nil { return nil, err }) is correct given checkFiredAlerts only ever returns a nil result paired with a non-nil error.
• Since Prepare always runs immediately before Start, state.End will be in the future for any non-zero duration, so completed inside checkFiredAlerts correctly evaluates to false on this first call — the immediate invocation doesn't risk short-circuiting the check as "completed" prematurely.
• The updated test (extalert/check_test.go:60) correctly switches from nil to a MockSplunkClient, consistent with the mock's usage pattern elsewhere in the file, since Start now performs a real client call.
• No race conditions or concurrency issues: no shared/global mutable state is introduced, and the per-run state pointer is only touched synchronously within the single call.

One minor, non-blocking observation: this means the Splunk FiredAlerts API is now called once at Start and again ~1s later at the first Status poll, slightly increasing API calls near the beginning of very short checks — but that's an inherent and reasonable trade-off for emitting the metric immediately, matching the PR's stated intent.

No bugs, security, or performance issues found.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
88.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud