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

[CahidArda]

Automated SDK Update

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

Server Change Summary

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

Based on my analysis of the PR diff, here's the structured summary:

Changes Summary

• Added a new /v2/readiness endpoint to check the readiness state of QStash
• Implemented a new readiness() handler function that returns HTTP 200 with "OK" response
• The endpoint follows the same pattern as the existing /v2/liveness endpoint

New APIs/Endpoints

• GET /v2/readiness
  • Parameters: None
  • Return type: HTTP 200 with plain text response "OK"
  • Purpose: Allows clients to check if QStash is ready to accept requests

Modified APIs/Endpoints

• None

Breaking Changes

• None

Notes for SDK Implementors

• This is a purely additive change - existing SDK functionality remains unchanged
• The readiness endpoint is optional to implement in SDKs, as it's a health check endpoint typically used for infrastructure/orchestration purposes (e.g., Kubernetes readiness probes)
• If implementing this in SDKs, it can be added as a simple health check method, similar to how liveness checks might be implemented
• The endpoint requires no authentication parameters in the diff shown
• Response is a simple plain text "OK" string with 200 status code
• This endpoint is distinct from liveness - readiness typically indicates the service is ready to handle traffic, while liveness indicates the service is running

SDK Change Plan

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

1. New Methods/Functions: Detailed specification for checkReadiness() method with abstract signatures, parameters, return types, and error conditions

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

3. New Types/Models: Defined ReadinessResponse type with field specifications and alternative approaches

4. Tests: Specified 7 test cases including:

   • Unit tests for success, errors, timeouts, and async variants
   • Integration tests for real endpoints and path verification

5. Documentation Updates: Comprehensive list covering:

   • API reference documentation
   • Getting started guides
   • Health check documentation
   • README and CHANGELOG updates

The plan also includes additional considerations for consistency, configuration, logging, metrics, and implementation priorities. Each section uses abstract notation (not language-specific) and provides specific details about parameters, return types, and edge cases as requested.

---

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/883