Emit ApiErrorOccurred metric for request timed out error

[m-Peter]

Closes: #931

Description

---

For contributor use:

• Targeted PR against master branch
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the standards mentioned here.
• Updated relevant documentation
• Re-reviewed Files changed in the Github PR explorer
• Added appropriate labels

Summary by CodeRabbit

• Bug Fixes
  • Improved error handling and monitoring for timeout scenarios in the API server. Enhanced tracking of timeout-related errors provides better visibility into system performance and reliability issues. These changes enable faster identification and resolution of timeout-related problems, helping maintain optimal API availability and performance.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The change introduces a new error code constant (errCodeTimeout) for handling timeout errors in JSON-RPC responses and adds metric emission for these timeout events alongside existing panic error handling in the API server.

Changes

Cohort / File(s)	Change Summary
Timeout error handling api/server.go	Added errCodeTimeout constant (-32002), expanded const block to include both timeout and panic error codes, and implemented ApiErrorOccurred metric emission when timeout errors are detected in API responses

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

• New constant addition is straightforward
• Metric emission logic follows existing panic handling pattern
• Changes are confined to a single file with clear, localized impact

Suggested labels

Improvement

Suggested reviewers

• janezpodhostnik
• zhangchiqing
• peterargue

Poem

🐰 A timeout caught, metrics ring true,
With errCodeTimeout (-32002) tracking through,
ApiErrorOccurred now emits its call,
When requests wear out and time's too tall! ⏱️

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: emitting ApiErrorOccurred metric for request timeout errors, which matches the primary objective.
Linked Issues check	✅ Passed	The pull request implements the objective from issue #931 by introducing errCodeTimeout and triggering ApiErrorOccurred metric for timeout errors.
Out of Scope Changes check	✅ Passed	All changes are scoped to implementing timeout error metric emission; no unrelated modifications detected.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch mpeter/request-timeout-emit-error-metric

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between bbeb971 and f4491e3.

📒 Files selected for processing (1)

• api/server.go (2 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Test

🔇 Additional comments (2)

api/server.go (2)

476-479: Logic is correct, pending error code verification.

The timeout handling implementation follows the same pattern as the panic handling above it and correctly emits the ApiErrorOccurred metric. The placement before the general error response handling (lines 481-508) ensures the metric is captured before the response is flushed.

Note: Unlike ServerPanicked(message.Error.Message), the ApiErrorOccurred() call doesn't pass the error message. This appears intentional based on the metric collector API design.

The correctness of this implementation depends on verifying the error code at lines 438-441 (see previous comment).

---

438-441: Error code -32002 is correct for timeout errors.

Verification confirms that -32002 is the standard error code returned by go-ethereum (Geth) for request timeouts. The implementation in lines 438-441 and the corresponding timeout handling at lines 477-479 are accurate.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[peterargue]

should we be emitting this metric any time message.Error != nil?

[m-Peter]

This is generally handled from the handleError function: https://github.com/onflow/flow-evm-gateway/blob/main/api/utils.go#L140-L142.

There are plenty of cases where message.Error != nil and the actual error is simply a user error, e.g.

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32602,
    "message": "too many arguments, want at most 0"
  }
}

Emitting the ApiErrorOccurred metric for such cases, would only cause false alerts.

We are only interested in the special case where message.Error.Code == errCodeTimeout, because in this case, the handleError function never gets called.