Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement] Custom Error response handling (NodeError Registry) #45

Open
nodiesBlade opened this issue Jun 18, 2024 · 2 comments
Open
Labels
enhancement New feature or request

Comments

@nodiesBlade
Copy link
Collaborator

nodiesBlade commented Jun 18, 2024

Context

Gateway operators want to punish node operators dependent on specific error messages (i.e., rate limiting) and the time to punish is opinionated.

Currently, there is a default behavior of a punishment (stop sending requests) of ~15 seconds whenever a node operator returns an unrelated POKT error/RPC error. The code can be found here.

Proposal

We can extend the gateway server error capabilities by allowing gateway operators to supply specific error substrings and a corresponding punishment duration for the node operator.

This information should be pulled from the PostgreSQL database table similiar fashion to any of our other registries. It could be called NodeErrorRegistry, and periodically updated. Whenever a node operator returns an error response, we can iterate over the rows returned from the NodeErrorRegistry and if there is a match, punish for the specified interval.

Suggested Schema:

  • error_substring (varchar) -> parsed as a string
  • punish_interval (varchar) -> parsed as time.Duration

Benefits

Gateway operators can now flexibly punish node operators on a per-need basis without debating what constitutes a "good" or "bad" error, and the appropriate punishment duration.

The gateway server principles is engrained to provide an opinionated for getting started, allowing gateway operators to fine-tune based on their clients' needs. Long term, we can then add databases migrations to include specific error messages where gateway operators agree that these errors provide unanimous benefits for operations. This is aligned with the "future" roadmap

Excerpt below

Over time, as more gateways enter the network, there will be re-occurring patterns on what is needed on the foundational level and developers can create RFPs to have them included. For example, while rate limiting and multi-tenancy endpoints feel too opinionated right now, there is a future where we can create a service that distributes these endpoints natively in the GW server. The use cases are limitless and we expect that over time, community contributions into the gateway server will enable some of the aforementioned use cases natively.

@nodiesBlade
Copy link
Collaborator Author

Andy from Liquify also mentions people can return these errors with a response 200. So this functionality should be extended to 2xx responses as well.

@nodiesBlade nodiesBlade added the enhancement New feature or request label Jun 18, 2024
@Andrew-Pohl
Copy link

Thanks Blade, I can look into this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants