Add more eval examples + filtering examples by language + fix git concurrent usage (#28719)

Release Notes:

- N/A

---------

Co-authored-by: michael <michael@zed.dev>
Co-authored-by: agus <agus@zed.dev>
This commit is contained in:
Thomas Mickley-Doyle
2025-04-14 22:05:46 +00:00
committed by GitHub
co-authored by michael agus
parent a8b1ef3531
commit d74f0735c2
76 changed files with 365 additions and 8 deletions
@@ -0,0 +1,3 @@
url = "https://github.com/matryer/goblueprints.git"
revision = "68041a598865cc3f4fa2acd4119081a2ea0826bf"
language_extension = "go"
@@ -0,0 +1,12 @@
1. The main.go changes introduce rate-limited endpoints by creating them via `MakeEndpoints` and passing them to both HTTP and gRPC servers instead of directly using the service. This includes:
- Adding endpoint creation before server startup
- Modifying HTTP server to use endpoints
- Modifying gRPC server to use endpoints
2. The server_grpc.go changes update the gRPC server implementation to use the provided endpoints instead of creating them internally. This affects both hash and validate endpoints which are now taken from the Endpoints struct rather than being created via makeHashEndpoint/makeValidateEndpoint.
3. The server_http.go changes mirror the gRPC server changes, modifying the HTTP server to use endpoints from the Endpoints struct rather than creating them internally for both hash and validate routes.
4. The service.go changes include:
- Renaming makeHashEndpoint to MakeHashEndpoint and making it public
- Renaming makeValidateEndpoint to MakeValidateEndpoint and making it public
- Adding new MakeEndpoints function that creates rate-limited endpoints using a token bucket (5 requests per second)
- Adding new dependencies for rate limiting (kitrl and ratelimit packages)
- The Endpoints struct remains the same but is now populated with rate-limited versions of the endpoints
@@ -0,0 +1,18 @@
Here’s a more abstract, goal-oriented version of your request without diving into implementation specifics:
---
### **Request: Add Rate Limiting to Vault Service**
We need to introduce rate limiting to our vault service to protect it from excessive traffic and ensure fair usage. The service currently handles password hashing and validation through both HTTP and gRPC, and we want to enforce a controlled request rate across all endpoints.
#### **Key Requirements:**
- Apply a global rate limit (e.g., 5 requests per second) to prevent abuse.
- Ensure the rate limiting works consistently across both HTTP and gRPC interfaces.
- Refactor the service to cleanly support rate limiting without breaking existing functionality.
- Maintain flexibility so that limits can be adjusted if needed.
#### **Implementation Approach (High-Level):**
- Use a token bucket or similar algorithm for smooth rate limiting.
- Integrate with our existing middleware/request pipeline.
- Keep the changes minimal but scalable for future adjustments.