docs: storage tasks - #2975
docs: storage tasks#2975TC-MO wants to merge 16 commits into
Conversation
The sharing procedure and the between-runs procedure were each written out four times, on the storage overview and all three type pages, with only the noun changed.
The overview's exception list omitted the request queue lock tier and the 40/s batch tier, so it understated the real limits.
The API reference link pointed at key-value stores, the #sharing anchor had no matching heading, and the description promised sharing content.
Record CRUD is a 200/s tier per openapi.yaml, not the 60/s default.
Nesting it under sharing implied a subset relationship that isn't there: granting a person access and addressing your own storage from code are unrelated mechanisms that only shared the word "share".
Request queue limits were lowered in apify-core#29428 (Jul 2026) to avoid DynamoDB partition throttling and the docs were never updated. Also documents the key-value store keys and records list tiers.
Drops a fabricated redoc anchor and corrects the key-value store records endpoint, which downloads a ZIP archive rather than listing records. Restores the concurrent write-order caveat to the storage overview.
The three per-type sections differed only in one method name and one client accessor, so the extraction had relocated duplication rather than removing it. One example per surface plus a lookup table covers all three.
The API client section led with the SDK's "open" flow; the replacement describes the client accessor, and the username/name form it documents is what both clients' to_safe_id conversions accept.
|
✅ Preview for this PR (commit |
… anchors Pre-signed URLs cover only selected dataset and key-value store endpoints, so the request queue stub dropped the claim. Headings keep master's #share id; the between-runs fragments decay deliberately - Docusaurus offsets only heading anchors, so span targets hide under the navbar.
One designed SVG, dead links stripped, SVGO) covers what datasets-app.png and find-store-id.png showed. overview-api.png was referenced nowhere.
Restatements only, checked by an independent fidelity review; the one factual change is Python SDK 3.8 -> 3.10, per its pyproject. Also drops the hub's dangling share paragraph and its stale concurrency note.
Fix broken example URLs and leftover filler.
janbuchar
left a comment
There was a problem hiding this comment.
Changes to the OpenAPI spec are fine.
szaganek
left a comment
There was a problem hiding this comment.
Just a few suggestions 🥲 I think we should add a note on using contractions to the style guide.
| Dataset storage enables you to sequentially save and retrieve data. A unique dataset is automatically created and assigned to each Actor run when the first item is stored. | ||
|
|
||
| Typically, datasets comprise results from web scraping, crawling, and data processing jobs. You can visualize this data in a table, where each object is forming a row and its attributes are represented as columns. You have the option to export data in various formats, including JSON, CSV, XML, Excel, HTML Table, RSS or JSONL. | ||
| Typically, datasets hold results from web scraping, crawling, and data processing jobs. The data displays as a table, where each object forms a row and its attributes form columns. You can export the data in JSON, CSV, XML, Excel, HTML table, RSS, or JSONL formats. |
There was a problem hiding this comment.
| Typically, datasets hold results from web scraping, crawling, and data processing jobs. The data displays as a table, where each object forms a row and its attributes form columns. You can export the data in JSON, CSV, XML, Excel, HTML table, RSS, or JSONL formats. | |
| Typically, datasets hold results from web scraping, crawling, and data processing jobs. The data is displayed as a table, where each object forms a row and its attributes form columns. You can export the data in JSON, CSV, XML, Excel, HTML table, RSS, or JSONL formats. |
| In [Apify Console](https://console.apify.com), you can view your datasets in the [Storage](https://console.apify.com/storage) section under the [Datasets](https://console.apify.com/storage?tab=datasets) tab. | ||
|
|
||
|  | ||
|  |
There was a problem hiding this comment.
In the output, there's some weird space under the screenshot. Can you check if you maybe exported some extra layers?
| 1. Click **Export** to download the data in your preferred format. | ||
|
|
||
| Utilize the **Actions** menu to modify the dataset's name, which also affects its [retention period](/storage#data-retention), and to adjust [access rights](/account/collaboration). The **API** button allows you to explore and test the dataset's [API endpoints](/api/v2/storage-datasets). | ||
| Use the **Actions** menu to rename the dataset (which affects its [retention period](/storage#data-retention)) and to adjust [access rights](/account/collaboration). Select **API** to view and test the dataset's [API endpoints](/api/v2/storage-datasets). |
There was a problem hiding this comment.
It's a good practice to start with the goal. Let's switch:
To rename the dataset...
To view and test...
| Utilize the **Actions** menu to modify the dataset's name, which also affects its [retention period](/storage#data-retention), and to adjust [access rights](/account/collaboration). The **API** button allows you to explore and test the dataset's [API endpoints](/api/v2/storage-datasets). | ||
| Use the **Actions** menu to rename the dataset (which affects its [retention period](/storage#data-retention)) and to adjust [access rights](/account/collaboration). Select **API** to view and test the dataset's [API endpoints](/api/v2/storage-datasets). | ||
|
|
||
|  |
There was a problem hiding this comment.
Is this screenshot necessary?
| API data push to a dataset is capped at _400 requests per second_ to avoid overloading the servers. | ||
|
|
||
| ::: | ||
| Pushes to a dataset are rate-limited; see [Rate limiting](#rate-limiting). |
There was a problem hiding this comment.
| Pushes to a dataset are rate-limited; see [Rate limiting](#rate-limiting). | |
| Pushes to a dataset are rate-limited. For details, see [Rate limiting](#rate-limiting). |
|
|
||
| Share storages by link using their ID or name. Whether the link works for others depends on your account or resource-level general access setting; learn how link-based access works in [General resource access](/account/collaboration/general-resource-access). | ||
|
|
||
| For one-off sharing of individual records or items when access is restricted, generate time-limited pre-signed URLs. These are available for selected dataset and key-value store endpoints only. See [Sharing restricted resources with pre-signed URLs](/account/collaboration/general-resource-access#pre-signed-urls). |
There was a problem hiding this comment.
Let's turn one-off sharing into simple English.
| import Tabs from '@theme/Tabs'; | ||
| import TabItem from '@theme/TabItem'; | ||
|
|
||
| If you have the storage's _name_ or _ID_, you can access it from any [Actor](../actors/index.mdx) or [task](../actors/running/tasks.md) run. Use the same methods and endpoints you'd use for the current run's storages. |
There was a problem hiding this comment.
Sounds like it's missing a link to these methods, the topic that explains it, or just a plain list.
|
|
||
| [Datasets](./dataset/index.md) and [key-value stores](./key_value_store/index.md) support concurrent use. Multiple Actors or tasks can write to the same dataset or key-value store, and multiple runs can read from them at the same time. | ||
|
|
||
| [Request queues](./request_queue.md) only allow multiple runs to add new data. A request queue can be processed by one Actor or task run at a time, unless you use [request locking](./request_queue.md#distributivity) to coordinate multiple runs. |
There was a problem hiding this comment.
| [Request queues](./request_queue.md) only allow multiple runs to add new data. A request queue can be processed by one Actor or task run at a time, unless you use [request locking](./request_queue.md#distributivity) to coordinate multiple runs. | |
| [Request queues](./request_queue.md) only allow multiple runs to add new data. A request queue can be processed by one Actor or task run at a time. However, you can use [request locking](./request_queue.md#distributivity) to coordinate multiple runs. |
|
|
||
| :::info Accessing restricted storage resources between runs | ||
|
|
||
| If a storage resource access is set to **Restricted**, the run from which it's accessed must have explicit access to it. Learn how restricted access works in [General resource access](/account/collaboration/general-resource-access), and how to grant it in [Share storage](./share.md). |
There was a problem hiding this comment.
| If a storage resource access is set to **Restricted**, the run from which it's accessed must have explicit access to it. Learn how restricted access works in [General resource access](/account/collaboration/general-resource-access), and how to grant it in [Share storage](./share.md). | |
| If a storage resource access is set to **Restricted**, the run from which it's accessed must have explicit access to it. Learn [how restricted access works](/account/collaboration/general-resource-access) and [how to grant it](./share.md). |
Do we need the titles?
| Only the method name changes with the storage type: | ||
|
|
||
| | Storage type | [JavaScript SDK](/sdk/js) | [Python SDK](/sdk/python) | | ||
| | --------------- | -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | |
There was a problem hiding this comment.
How the heck did this table pass the checks, mine always fail if there's as much as a single extra character :D
Sharing and cross-run usage were documented three times over, once per storage type, and had drifted apart; this consolidates them into two shared pages (Share storage, Use storage from another run) that the type pages now link to. Along the way it corrects the storage rate limits against
apify-core.