Batch operations throw on HTTP 400 instead of returning per-target results (RSA17c, BAR2, BGF2, RSC24)

[paddybyers]

Spec points

• RSA17c: `revokeTokens()` should normalise the server response into `{successCount, failureCount, results}`.
• BAR2, BGF2, RSC24: When the server returns HTTP 400 with `{error, batchResponse}` for mixed or all-failure batch presence results, the SDK should normalise the response into `{successCount, failureCount, results}`.

Observed behaviour

Both `batchPresence()` and `revokeTokens()` use `Resource.get()` / `Resource.post()` with `throwError=true`. Any HTTP 400 response sets `result.err`, which is thrown. The `batchResponse` data containing per-target success/failure results is discarded.

For `revokeTokens()`, the server response body is also passed through as-is rather than normalised.

Failing tests (7)

Test	File	Issue
`RSA17c_2 - mixed result normalised`	`revoke_tokens.test.ts`	Throws on HTTP 400 instead of returning results
`RSA17c_3 - all failure normalised`	`revoke_tokens.test.ts`	Same
`TRF2_1 - failure details in results`	`revoke_tokens.test.ts`	Same
`BAR2_1 - mixed results normalised`	`batch_presence.test.ts`	Throws on HTTP 400
`BAR2_3 - all failure normalised`	`batch_presence.test.ts`	Same
`BGF2_1 - failure result normalised with error details`	`batch_presence.test.ts`	Same
`RSC24_Mixed_1 - mixed results normalised`	`batch_presence.test.ts`	Same

Reproduction

```bash
RUN_DEVIATIONS=1 npx mocha --grep "RSA17c_2|RSA17c_3|TRF2_1" test/uts/rest/auth/revoke_tokens.test.ts
RUN_DEVIATIONS=1 npx mocha --grep "BAR2_1|BAR2_3|BGF2_1|RSC24_Mixed" test/uts/rest/batch_presence.test.ts
```

From PR #2191, branch `uts-rest`.

┆Issue is synchronized with this Jira Task by Unito

[SimonWoolf]

The batchResponse data containing per-target success/failure results is discarded.

There is no batchResponse field for partial success-failures any more, there hasn't been since wire protocol v3: https://github.com/ably/realtime/issues/4186 . The spec contains no references to the old format, so I'm not sure where all this is coming from.

[paddybyers]

I'm not sure where all this is coming from

Claude made a request against the endpoint, didn't realise it needed to send a v param, and got the old-format response.

[paddybyers]

Resolution: Not a deviation — UTS test mocks were wrong

Root cause

The UTS test specs were written assuming the legacy server response format (no X-Ably-Version header):

• All-success: plain array, HTTP 200
• Mixed/failure: {error, batchResponse}, HTTP 400

All current SDKs send X-Ably-Version >= 3 (ably-js sends version 6). With this header, the server returns a BatchResult envelope for all batch responses:

{
  "successCount": 1,
  "failureCount": 1,
  "results": [
    {"target": "clientId:alice", "issuedBefore": ..., "appliesAt": ...},
    {"target": "invalidType:abc", "error": {"code": 40000, ...}}
  ]
}

This is returned with HTTP 200 even for mixed success/failure. Since the server provides the envelope directly, no client-side transformation is needed — ably-js correctly passes through the response.

The "deviation" where ably-js throws on HTTP 400 is never triggered because the server never returns HTTP 400 with the version header.

Verified by

Diagnostic scripts hitting the Ably sandbox confirmed:

• Without X-Ably-Version: legacy format (plain arrays / {error, batchResponse} with HTTP 400)
• With X-Ably-Version: 6: BatchResult envelope with HTTP 200 for all cases

Fixes applied

• UTS specs (specification@1f9efc67): Updated all batch_presence and revoke_tokens mock responses to use the BatchResult envelope format
• ably-js tests (ably-js@73f6568a): Updated mock responses, removed 8 deviation skips (4 in batch_presence, 4 in revoke_tokens). All 30 tests now pass.
• deviations.md: Removed the two deviation sections for these spec points

Closing as resolved — no ably-js code change needed.