Draft
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #719 +/- ##
==========================================
- Coverage 86.64% 86.24% -0.40%
==========================================
Files 48 48
Lines 2920 2886 -34
==========================================
- Hits 2530 2489 -41
- Misses 390 397 +7
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
a45f20c to
4270cb9
Compare
c26dd9f to
7d6dbb1
Compare
3e14e50 to
12a29ae
Compare
ba4d354 to
e094d6a
Compare
This was referenced Feb 5, 2026
4528205 to
9c44f3b
Compare
vdusek
added a commit
to apify/apify-client-python
that referenced
this pull request
Feb 23, 2026
### Summary This is a major refactoring that introduces fully typed Pydantic models throughout the client library. The models are generated from the OpenAPI specifications. All API responses now return typed objects instead of raw dictionaries. This follows up on apify/apify-docs#2182. ### Issues - Closes: #21 - Closes: #481 ### Packages - Add direct dependency on `Pydantic`. - Removes the dependency on `apify-shared`. - Add dev dependency [datamodel-code-generator](https://koxudaxi.github.io/datamodel-code-generator/) for model generation. ### Key changes - Uses [datamodel-code-generator](https://koxudaxi.github.io/datamodel-code-generator/) tool configured via `pyproject.toml` to generate Pydantic models based on the [OpenAPI specs](https://docs.apify.com/api/openapi.json). - Refactors the whole codebase to adopt the new generated models. - All resource clients now return typed Pydantic models (`Actor`, `Task`, `Run`, etc.). - Adds response wrappers for validating and extracting API response data. - Updates list methods to return typed pagination models. - Documentation examples now use typed attribute access. - Updates the SDK to use the new typed client. - See the corresponding PR in `apify/apify-sdk-python` for details - apify/apify-sdk-python#719. - It will be merged later. ### Architecture - Get rid of 3/4/5 levels of inheritance. - Get rid of inline imports because of circular dependencies. - I had to utilize `ClientRegistry` to be able to achieve that (because of resource clients-siblings imports). ### Breaking changes - Client methods now return Pydantic models instead of dicts. - Access patterns change from dict-style (`result['key']`) to attribute-style (`result.key`). ### Test plan - Updated test concurrency to 16 workers. - A lot of new tests were implemented - coverage ~95%. - Unit tests - do not call production API, only for testing utils or other functionality using mocks. - Integration tests - call production API. - Thanks to the new tests, I was able to do a lot of fixes in the OpenAPI specs. ### Next steps - Explore the generation of resource clients using [openapi-python-client](https://github.com/openapi-generators/openapi-python-client). - Fully automate model updates based on changes in [apify-api/openapi](https://github.com/apify/apify-docs/tree/master/apify-api/openapi). - This will be released as part of the Apify client v3.0.
9c44f3b to
8057e7c
Compare
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Move ActorEnvVars, ApifyEnvVars, ActorExitCodes, ActorEventTypes, and env var type classification lists from apify-shared into apify._consts. Update all imports across src/ and tests/. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…sification lists to test file, inline BASE64_REGEXP Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…Run, import pricing models from client Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
8057e7c to
05a8aba
Compare
The v3 client now validates pricing_infos dicts through pydantic models before sending to the API. Add required CommonActorPricingInfo fields (apifyMarginPercentage, createdAt, startedAt) to all pricing info dicts in test fixtures and cleanup code. Also fix UTC import missing inside serialized Actor main functions for timeout tests. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…and tolerate platform pricing-info env var omissions apify-client v3 split the single `timeout` kwarg on `actor.start/call` and `task.call` into `run_timeout` (server-side Actor-run timeout) and `timeout` (HTTP request timeout). The SDK kept passing the inherited remaining-time to `timeout=`, so the new run received the default platform timeout, breaking the `inherit` timeout propagation. The v3 pricing models also require `apifyMarginPercentage`, `createdAt`, `startedAt`, and per-event `eventDescription`, but the platform's `APIFY_ACTOR_PRICING_INFO` env var does not include them, so Configuration() raised ValidationError on Actor startup. Inject safe defaults in a BeforeValidator so validation succeeds on the Actor side. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The platform sets APIFY_ACTOR_PRICING_INFO to `{}` for Actors without a
configured pricing model. The previous normalizer injected default
fields but left the `pricingModel` discriminator missing, causing the
apify-client pydantic union to fail with `union_tag_not_found` and every
Actor run to crash on startup with a ValidationError.
Treat an empty JSON object (and already-parsed non-dict values) as
"no pricing info" so the union resolves to `None`, matching the pre-v3
behavior where `data or None` handled the same case.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The cleanup in make_actor appended a FREE pricing_info with a hardcoded startedAt='2024-01-01', which the API rejected for actors that already had later-dated pricing records with "The record you are adding must start after all existing records." Compute startedAt as max(latest_existing, now) + 1s so the added record always starts strictly after existing ones. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
apify-python-clientv3, which introduces fully typed API clients generated from OpenAPI specifications.Issues
Testing
apify-python-clientv3.