Skip to content

Design a coherent, consistent validation strategy across all HTTP service features #2547

@coolwednesday

Description

@coolwednesday

Counter view: In case there's an error in the initialisation which was logged and application launched, subsequent operations would not work as intended and the developer is left digging for the root cause. Given that the warning logs come only during the start of the app, developer would need to know that they should

Recommendation: We should allow the developer to decide if they want to enforce strict validation or allow the app to run in case of these validation failures. This would be particularly helpful for the production environments where strict configuration would be preferred.

My Perspective

I agree with the direction, but I’d prefer that this feature not be implemented specifically for the rate limiter alone. Instead, this should be part of a broader, comprehensive HTTP Service configuration strategy—covering auth, headers, rate limiting, and all other optional HTTP features uniformly.

For now, this PR can address the rate limiter behaviour as intended. But for v2, we should propose a unified and robust validation mechanism across all HTTP features. Implementing strict validation for one feature and silent-failure behaviour for others makes the overall HTTP service feel inconsistent and unpredictable.

Developers shouldn’t have to remember which optional features require strict attention and which ones silently fail. Either all optional features follow strict validation, or all follow soft-validation—consistency is key. The current mix forces developers to be cautious in some places and not in others, increasing cognitive overhead and onboarding friction.

In summary:
✔ This PR → proceed with the rate-limiter change
✔ v2 → design a coherent, consistent validation strategy across all HTTP service features

Let me know, if that works for you, we will create a issue ticket to track this.

Originally posted by @coolwednesday in #2378

GoFr's v2 → design a coherent, consistent validation strategy across all HTTP service features

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions