Skip to content

refactor!: Adapt to apify-client v3 [WIP]#719

Draft
vdusek wants to merge 10 commits intomasterfrom
adapt-to-apify-client-v3
Draft

refactor!: Adapt to apify-client v3 [WIP]#719
vdusek wants to merge 10 commits intomasterfrom
adapt-to-apify-client-v3

Conversation

@vdusek
Copy link
Copy Markdown
Contributor

@vdusek vdusek commented Dec 23, 2025

Description

Issues

Testing

  • The existing SDK tests pass with apify-python-client v3.

@vdusek vdusek self-assigned this Dec 23, 2025
@github-actions github-actions bot added this to the 130th sprint - Tooling team milestone Dec 23, 2025
@github-actions github-actions bot added t-tooling Issues with this label are in the ownership of the tooling team. tested Temporary label used only programatically for some analytics. labels Dec 23, 2025
@vdusek vdusek added the adhoc Ad-hoc unplanned task added during the sprint. label Dec 23, 2025
@codecov
Copy link
Copy Markdown

codecov bot commented Dec 23, 2025

Codecov Report

❌ Patch coverage is 92.27053% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.24%. Comparing base (bd7a715) to head (a5fb9c8).
⚠️ Report is 1 commits behind head on master.

Files with missing lines Patch % Lines
src/apify/_actor.py 67.56% 12 Missing ⚠️
...ify/storage_clients/_apify/_api_client_creation.py 66.66% 1 Missing ⚠️
...rc/apify/storage_clients/_apify/_dataset_client.py 66.66% 1 Missing ⚠️
.../storage_clients/_apify/_key_value_store_client.py 80.00% 1 Missing ⚠️
...age_clients/_apify/_request_queue_single_client.py 95.23% 1 Missing ⚠️
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     
Flag Coverage Δ
e2e 35.27% <46.85%> (-2.61%) ⬇️
integration 57.58% <74.39%> (-1.70%) ⬇️
unit 73.59% <68.59%> (-1.10%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@vdusek vdusek force-pushed the adapt-to-apify-client-v3 branch from a45f20c to 4270cb9 Compare January 2, 2026 12:45
@vdusek vdusek force-pushed the adapt-to-apify-client-v3 branch from c26dd9f to 7d6dbb1 Compare January 9, 2026 14:27
@vdusek vdusek force-pushed the adapt-to-apify-client-v3 branch 3 times, most recently from 3e14e50 to 12a29ae Compare January 23, 2026 14:25
@vdusek vdusek force-pushed the adapt-to-apify-client-v3 branch from ba4d354 to e094d6a Compare January 27, 2026 14:09
@vdusek vdusek force-pushed the adapt-to-apify-client-v3 branch from 4528205 to 9c44f3b Compare February 23, 2026 11:00
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.
@vdusek vdusek changed the title chore: Adapt to apify-client v3 [WIP] refactor!: Adapt to apify-client v3 [WIP] Mar 10, 2026
@vdusek vdusek force-pushed the adapt-to-apify-client-v3 branch from 9c44f3b to 8057e7c Compare April 16, 2026 12:56
vdusek and others added 6 commits April 16, 2026 15:02
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>
@vdusek vdusek force-pushed the adapt-to-apify-client-v3 branch from 8057e7c to 05a8aba Compare April 16, 2026 13:07
vdusek and others added 4 commits April 16, 2026 15:38
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

adhoc Ad-hoc unplanned task added during the sprint. t-tooling Issues with this label are in the ownership of the tooling team. tested Temporary label used only programatically for some analytics.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Adapt to typed apify-client-python

2 participants