Skip to content

docs(programming-interface): add "Persisting state across runs" page#2739

Draft
DaveHanns wants to merge 1 commit into
apify:masterfrom
DaveHanns:fix/f70-persisting-state-docs
Draft

docs(programming-interface): add "Persisting state across runs" page#2739
DaveHanns wants to merge 1 commit into
apify:masterfrom
DaveHanns:fix/f70-persisting-state-docs

Conversation

@DaveHanns

Copy link
Copy Markdown
Contributor

Summary

Adds a new page under Programming interface that documents a pattern the current docs don't cover: how a scheduled or cron-driven Actor can read data written by a previous run of itself.

Two patterns are presented with runnable JavaScript and Python snippets:

  1. Read the previous run's default key-value store. List previous SUCCEEDED runs via the API (using a user-supplied token so it works under limited permissions), then read a STATE record from that run's default KVS.
  2. Named key-value store. The classic Actor.openKeyValueStore('name') pattern, together with a :::caution block that spells out the limited-permissions edge cases (stores created under full permissions aren't visible to limited-permissions runs; stores are per-user).

A side-by-side comparison table helps the reader choose between the two.

Related touch-ups

  • actor.json reference: clarified that environmentVariables is a JSON object (not an array), and documented the "@secretName" reference form for values managed via apify secrets add. This is where new users trip up first.
  • Programming interface landing page (index.mdx): added a card linking to the new page.

Test plan

  • New page renders in the Docusaurus preview under Programming interface.
  • Cross-links (to actor.json, environment variables, permissions, migration guide, key-value store, storage pages) resolve.
  • JS and Python code samples are syntactically valid and follow the SDK's current API surface.

Surfaced during an evaluation of Apify surfaces for agent-driven Actor development.

Adds guidance for a common pattern that isn't currently covered in the
docs: how a scheduled/cron-driven Actor can read data written by a
previous run of itself.

- New page under Programming interface with two recommended patterns
  (list previous runs via the API vs. named key-value store), a
  side-by-side comparison, and the caveats around named storages under
  limited permissions.
- Cross-links from the Programming interface landing card grid.
- Clarifies in the `actor.json` reference that `environmentVariables`
  is a JSON object (not an array) and documents the `@secretName`
  reference form.

Surfaced during an evaluation of Apify surfaces for agent-driven Actor development.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants