Better error classification in clients/feeder

[ashu26jha]

Problem

Currently, if we try to fetch the block (lets say 1,000,000) from the feeder we get 400 Bad Request which is a generic error. Meanwhile the feeder gateway shows:

{"code": "StarknetErrorCode.BLOCK_NOT_FOUND", "message": "Block number 1000000 was not found."}

We want the error message to reflect the response.

Advantages

1. This will help in debugging.
2. This will be needed to improve reorg handling

[ashu26jha]

#1820

[anubhavitis]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I have over 2 years of experience in building Go-based applications, having worked with companies like CoinSwitch and currently Fileverse. I have designed, built, and deployed services from scratch that cater to hundreds of thousands of users daily. My expertise spans supporting both Web2 applications and Web3 dApps, making me well-equipped to contribute effectively to your project

How I plan on tackling this issue

Things that are on top of my mind:

• Review the code where the block fetch request is made and where the error is being handled.
• Locate the part of the code that translates errors from the feeder gateway into HTTP responses.
• Update the error handling logic to capture specific error responses from the feeder gateway.
• Modify the HTTP response to include the specific error message from the feeder gateway.
• tests: unit tests and over staging/dev environments

[CollinsC1O]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I'm a frontend and a smart contract developer. I have provided certain solutions to several problems. i will love to work on this issue

How I plan on tackling this issue

To improve error classification in clients/feeder:

Update Error Handling: I will modify the feeder's error-handling code to catch specific errors and relay them accurately.

Enhance Error Mapping: I will map specific error codes (like BLOCK_NOT_FOUND) to precise error messages.

Update Feeder Responses: I will ensure that the feeder sends detailed error responses that reflect the actual issue, such as {"code": "StarknetErrorCode.BLOCK_NOT_FOUND", "message": "Block number 1000000 was not found."}.

Test Changes: I will validate that errors are classified correctly and messages are precise through unit and integration tests.

[Tchisom17]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I am a Golang developer with experience in building backend systems and working on decentralized applications (dApps). My background includes integrating with APIs, handling error responses, and creating resilient systems that can manage various failure scenarios, such as reorgs in blockchain networks.

I have also worked with various smart contract frameworks and have experience troubleshooting and improving error handling in different environments. This experience will allow me to implement clear error classification that directly reflects the responses from external systems, which will improve debugging and support future feature implementations.

How I plan on tackling this issue

To approach the problem, I would first review the existing error handling mechanism in the clients/feeder code to understand how the current 400 Bad Request errors are generated. The goal is to identify why specific error messages, such as StarknetErrorCode.BLOCK_NOT_FOUND, are not being captured properly.

Next, I would modify the error handling logic to parse the response body from the feeder gateway and extract the specific error messages. This will allow for the creation of more meaningful errors that reflect the actual problem, such as block-not-found errors.

I would then refactor the feeder client to classify errors based on the feeder gateway's response codes and messages. By introducing specific error types, such as BlockNotFoundError, the system can provide clearer feedback, improving both debugging and reorg handling.

Finally, I would ensure proper testing by simulating different error scenarios and validating that the new error handling works as expected. This would make future improvements, such as handling blockchain reorgs, easier to implement and manage.

[llamitaOnfire]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

Hi! I’m a Computer Engineering student with a strong foundation in web development, currently expanding my skills in blockchain technology. I’m also an enthusiastic open source contributor, eager to apply my problem-solving skills in real-world projects. My background in web development has equipped me with experience in debugging, error handling, and API interactions, which I believe can be useful in addressing this issue.

How I plan on tackling this issue

To tackle this issue, I will start by examining the current feeder response handling logic. I’ll work to identify where the generic 400 Bad Request error is being returned, then modify the logic to pass along the more specific error message provided by the feeder gateway. My goal is to ensure that the error message accurately reflects the StarknetErrorCode.BLOCK_NOT_FOUND response when a block is not found, which will improve clarity and help with debugging.

Additionally, I’ll ensure that the changes will smoothly integrate with any future reorg handling improvements, as noted in the issue description.

Looking forward to contributing!