Problem
PR #18 added getRecipients to all six language references in the turbodocx-sdk skill, but only added two eval cases:
- id 45 — Express (JavaScript/TypeScript)
- id 46 — Spring Boot (Java)
Python, Go, PHP and Ruby got documentation with no eval coverage. A regression in those four templates — a wrong method name, a dropped await, a swallowed error return — would not be caught by claude evals run evals/evals.json.
This matters more than usual for this method because the SDKs expose it under four different shapes:
| Language |
Call |
| Python |
await TurboSign.get_recipients(document_id) |
| Go |
GetRecipients(ctx, documentID) |
| PHP |
getRecipients($documentId) |
| Ruby |
get_recipients(document_id) |
Why it's worth covering
Two failure modes are specific to this method and produce code that looks correct:
- Reaching for
getStatus instead. It returns only { status } — the document-level state — so it cannot answer "who has signed and who are we still waiting on". Generated code compiles and runs, and answers the wrong question.
- Branching on
status instead of effectiveStatus. There is no per-recipient declined/voided/expired state, so on a voided or expired document an unsigned signer still reads pending in status. Code branching on it chases people whose signing links are already dead.
Both are asserted in evals 45/46 and should be asserted for the other four languages too.
Per-language traps also worth pinning:
- Python — the method is async; a bare call returns a coroutine rather than the roster.
- Go — takes a
context.Context first argument and returns a two-value (result, error); a discarded error hides the failure.
Proposed fix
Add eval ids 50–53 covering FastAPI, Gin, Laravel and Rails, modelled on the existing 45/46 and using each SDK's real method shape.
Verified against a live endpoint
The underlying endpoint was exercised end to end on staging through a document's full lifecycle (sent → resent → viewed → signed), 16/16 assertions passing at every step, so the behaviour these evals describe is confirmed rather than assumed.
Problem
PR #18 added
getRecipientsto all six language references in theturbodocx-sdkskill, but only added two eval cases:Python, Go, PHP and Ruby got documentation with no eval coverage. A regression in those four templates — a wrong method name, a dropped
await, a swallowed error return — would not be caught byclaude evals run evals/evals.json.This matters more than usual for this method because the SDKs expose it under four different shapes:
await TurboSign.get_recipients(document_id)GetRecipients(ctx, documentID)getRecipients($documentId)get_recipients(document_id)Why it's worth covering
Two failure modes are specific to this method and produce code that looks correct:
getStatusinstead. It returns only{ status }— the document-level state — so it cannot answer "who has signed and who are we still waiting on". Generated code compiles and runs, and answers the wrong question.statusinstead ofeffectiveStatus. There is no per-recipient declined/voided/expired state, so on a voided or expired document an unsigned signer still readspendinginstatus. Code branching on it chases people whose signing links are already dead.Both are asserted in evals 45/46 and should be asserted for the other four languages too.
Per-language traps also worth pinning:
context.Contextfirst argument and returns a two-value(result, error); a discarded error hides the failure.Proposed fix
Add eval ids 50–53 covering FastAPI, Gin, Laravel and Rails, modelled on the existing 45/46 and using each SDK's real method shape.
Verified against a live endpoint
The underlying endpoint was exercised end to end on staging through a document's full lifecycle (sent → resent → viewed → signed), 16/16 assertions passing at every step, so the behaviour these evals describe is confirmed rather than assumed.