Giza integration tests: Distributor node: Managing buckets

Preconditions:

• A running Joystream node
• A running query-node
• A running storage node which has sufficient limits set to handle the scenario
• A running distributor node which has sufficient limits set to handle the scenario

Variables:

• c - distributor node's config.intervals.cacheCleanup value

Flow:

1. Create 3 data objects (A, B, C) and upload them to 3 separate bags (bA, bB and bC, for example: static:council, static:wg:content, static:wg:storage or 3 separate channel bags)
2. Assign the bags to the distributor node bucket
3. Send POST request to operator/api/v1/set-buckets setting the buckets to [bA]
4. Send GET request to /api/v1/buckets
5. Expect { "bucketIds": [bA] } response
6. Request assets A, B, C
7. Expect responses:
   • A: 200 OK
   • B: 421 Misdirected request
   • C: 421 Misdirected request
8. Send POST request to operator/api/v1/set-buckets setting the buckets to [bB, bC]
9. Send GET request to /api/v1/buckets
10. Expect { "bucketIds": [bB, bC] } response
11. Wait c seconds
12. Request assets A, B, C
13. Expect responses:

• A: 421 Misdirected request
• B: 200 OK
• C: 200 OK

14. Send POST request to operator/api/v1/set-buckets setting the buckets to all (empty value)
15. Send GET request to /api/v1/buckets
16. Expect { "allByWorkerId": operatorId } response
17. Request assets A, B, C
18. Expect all 200 OK responses

Start by locating the Giza integration-test suite and the distributor operator endpoints named in the issue: operator/api/v1/set-buckets, /api/v1/buckets, and asset requests. Reproduce the flow with a running Joystream node, query-node, storage node, and distributor node; done means the bucket responses and all listed 200 OK or 421 Misdirected request results match the expectations before and after cache cleanup.