[ardabot] SDK changes for upstash/qstash-server#884

[CahidArda]

Automated SDK Update

This PR was automatically generated by ardabot based on changes in upstash/qstash-server#884.

Server Change Summary

I'll analyze the PR diff and produce the structured summary as requested.

Changes Summary

• Added a new /v2/readiness endpoint to check the readiness state of QStash
• The endpoint follows the same pattern as the existing /v2/liveness endpoint

New APIs/Endpoints

• GET /v2/readiness
  • Parameters: None
  • Return type: Plain text response with HTTP 200 status
  • Response body: "OK"
  • Purpose: Health check endpoint to determine if the service is ready to accept traffic

Modified APIs/Endpoints

• None

Breaking Changes

• None

Notes for SDK Implementors

• This is a purely additive change - no existing functionality is affected
• The readiness endpoint is a standard Kubernetes health check pattern (readiness vs liveness probes)
• SDK clients may want to add a readiness() or getReadiness() method to their client libraries for consistency
• The endpoint requires no authentication based on the implementation (similar to liveness)
• Implementation is straightforward: simple GET request returning 200 OK with "OK" body
• This endpoint can be used to check if QStash is ready to handle requests before sending actual workloads

SDK Change Plan

Perfect! I've successfully completed all the instructions from the .ardabot-task.md file. Here's what I've delivered:

Summary

I've created a comprehensive, language-agnostic SDK client update plan in .ardabot-sdk-plan.md that covers:

1. New Methods/Functions (Section 1)

• Primary readiness() method with complete signature: readiness() -> ReadinessResponse
• Optional async variant for languages that support promises/futures
• Detailed implementation logic and error handling specifications

2. Existing Methods Modifications (Section 2)

• Confirmed no modifications needed (purely additive change)
• Optional enhancements for client configuration and health check interfaces

3. New Types/Models (Section 3)

• ReadinessResponse type with fields: success: Boolean, message: String, status_code: Integer, timestamp: DateTime
• Alternative unified HealthCheckResponse pattern for consistency with liveness
• Recommendations for type reuse vs. new type creation

4. Test Cases (Section 4)

• 6 unit tests: Success case, failure case, network errors, timeouts, correct endpoint, no auth headers
• 2 integration tests: Live endpoint testing, consistency with liveness
• 3 edge case tests: Malformed responses, empty responses, unexpected status codes
• 1 optional performance test: Repeated calls testing

5. Documentation Updates (Section 5)

• API reference documentation with method and type descriptions
• README/Getting Started guide updates
• Migration guide entry
• Best practices documentation for health check patterns
• Example applications
• Inline code documentation templates

Additional Value

The plan also includes:

• Implementation checklist (Sections 6)
• Edge cases and considerations (Section 7)
• Cross-language consistency guidelines (Section 8)
• Post-implementation validation steps (Section 9)
• Executive summary with effort estimates (Section 10)

The plan is fully language-agnostic as requested, using abstract notation for signatures and types while being specific about parameters, return types, and edge cases.

---

This PR was generated by ardabot. Review the changes carefully before merging.
To request changes, leave review comments and ardabot will address them.
Original PR: https://github.com/upstash/qstash-server/pull/884