Response validation raises a raw pydantic ValidationError that is not an ApifyClientError #1170

Resource methods turn API responses into models with <Model>.model_validate(...), for example ActorClient.get. There are about 160 such calls and none of them catches the error, so a response that does not match the model raises pydantic.ValidationError. That class does not inherit from ApifyClientError, so except ApifyClientError does not catch it, and the message says nothing about which request failed. The only place that catches it is UserClient.get (#L60-L65, #L183-L188), where it is used to pick between the private and public user model.

This is what users saw in #811, #822 and #829: after an API or spec drift, client.actor(...).get() and .call() failed with "N validation errors for ActorResponse", and code that guards client calls with except ApifyClientError crashed.

The JS client wraps schema failures in ResponseValidationError, a subclass of ApifyClientError. parseResponse (utils.ts#L116-L128) raises it with the request method and URL, the structured issues, and the original zod error as cause, plus a hint asking the user to report the mismatch.

Expected behavior

Validate responses through one helper that catches pydantic.ValidationError and raises a ResponseValidationError(ApifyClientError, ValueError) carrying the HTTP method, the URL, errors() from pydantic, and the original exception as __cause__. UserClient.get keeps catching the raw error internally for its private/public fallback.

✍️ Drafted by Claude Code