[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 now analyze the PR diff and provide a structured summary for SDK implementors.

Analysis of QStash Server PR: Readiness API

Changes Summary

• Added a new /v2/readiness endpoint to the QStash public API
• Created a new readiness() handler function in pkg/api/public/liveness.go
• Registered the readiness endpoint in the server setup (pkg/api/public/server.go)

New APIs/Endpoints

• GET /v2/readiness
  • Parameters: None
  • Return type: HTTP 200 OK with "OK" string response body
  • Purpose: Health check endpoint to verify the service is ready to accept requests

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 follows the same pattern as the existing liveness endpoint (GET /v2/liveness)
• Both endpoints return a simple 200 OK status with "OK" string body
• SDK clients may want to expose a .readiness() or .checkReadiness() method for consistency with the existing .liveness() pattern (if implemented)
• This endpoint is typically used for Kubernetes readiness probes or similar health monitoring systems
• No authentication appears to be required for this endpoint (similar to the liveness endpoint)
• SDK implementation is optional - this is primarily an infrastructure/operations endpoint rather than a core API feature

SDK Change Plan

I've completed the task as requested. I created a comprehensive, language-agnostic plan for updating SDK clients to support the new /v2/readiness endpoint. The plan includes:

1. New Methods/Functions: Detailed the readiness() primary method and an optional checkReadiness() convenience method with abstract signatures and behavior specifications.

2. Existing Methods to Modify: Confirmed no modifications needed (purely additive change).

3. New Types/Models: Defined the ReadinessResponse type with field descriptions and alternative approaches to match existing SDK patterns.

4. Tests to Write: Specified 6 comprehensive test cases covering success scenarios, error handling, URL construction, timeouts, and boolean convenience methods.

5. Documentation to Update: Detailed updates needed for API reference docs, README, changelog, code examples, and API coverage matrix.

Additionally, the plan includes:

• Implementation priority guidance (LOW to MEDIUM)
• Edge cases and considerations (authentication, caching, logging, circuit breakers, etc.)
• Cross-SDK consistency requirements

The plan is completely language-agnostic, using abstract notation for signatures and types, making it applicable to any SDK implementation (TypeScript, Python, Go, Java, etc.).

---

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