You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given the discussion here apify/crawlee-python#1669 (comment)
the Actor.use_state should access the same state as the first default crawler. So key CRAWLEE_STATE_0 (depends on the implementation there)
Huh, I should have checked this before, but we apparently use different default state keys in the SDK and in crawlee, so what I was highlighting here (mismatch between the SDK and context version) is not really a problem.
Now I'm not so sure if we should share the default key, I saw it as a nasty BC, but if it didn't work like that before, I guess we should keep the current JS behavior, so keep different default state keys for SDK and BasicCrawler.
Given we want to split the Crawlee state to have a separate one for each Crawler instance, it doesn't really make sense to me to add SDK support on top of this.
JS and Python SDK sharing the same state (key) on Actor.useState / Actor.use_state sounds nice and IMO sells the idea it's actually the "Actor's state", not some random KVS value.
it doesn't really make sense to me to add SDK support on top of this.
Care to elaborate? It sounds like you don't want to have Actor.useState at all, but I am sure that's not the case?
Right now I am inclined to keep the JS behavior, with a fixed SDK state key, and do the same in Python, so Actor.useState in JS uses the same state key as Actor.use_state in Python.
Activity
B4nan commentedon Jan 15, 2026
IMO nothing to consider here, this is missing, it should be here, let's add it asap so we don't block that docs PR.
B4nan commentedon Jan 15, 2026
@Mantisus can you look into this please?
Pijukatel commentedon Jan 15, 2026
It has to take this into account apify/crawlee-python#1669
Given the discussion here apify/crawlee-python#1669 (comment)
the
Actor.use_stateshould access the same state as the first default crawler. So keyCRAWLEE_STATE_0(depends on the implementation there)B4nan commentedon Jan 16, 2026
Huh, I should have checked this before, but we apparently use different default state keys in the SDK and in crawlee, so what I was highlighting here (mismatch between the SDK and context version) is not really a problem.
https://github.com/apify/crawlee/blob/master/packages/basic-crawler/src/internals/basic-crawler.ts#L491
https://github.com/apify/apify-sdk-js/blob/master/packages/apify/src/actor.ts#L1593
Now I'm not so sure if we should share the default key, I saw it as a nasty BC, but if it didn't work like that before, I guess we should keep the current JS behavior, so keep different default state keys for SDK and BasicCrawler.
Thoughts @barjin @janbuchar @Pijukatel?
barjin commentedon Jan 16, 2026
Given we want to split the Crawlee state to have a separate one for each Crawler instance, it doesn't really make sense to me to add SDK support on top of this.
JS and Python SDK sharing the same state (key) on
Actor.useState/Actor.use_statesounds nice and IMO sells the idea it's actually the "Actor's state", not some random KVS value.B4nan commentedon Jan 16, 2026
Care to elaborate? It sounds like you don't want to have
Actor.useStateat all, but I am sure that's not the case?Right now I am inclined to keep the JS behavior, with a fixed SDK state key, and do the same in Python, so
Actor.useStatein JS uses the same state key asActor.use_statein Python.Mantisus commentedon Jan 16, 2026
I favor using different base keys for
use_statein Crawlee and SDK. And accordingly, using the same keyAPIFY_GLOBAL_STATEin Python and JS.These are different entities, and as a user, I would expect the data in
use_stateto be associated only with a specific entity.feat: Add `Actor` method `use_state` (apify#738)