draft: add stamp-expiry beekeeper check#591
Conversation
new integration check that buys a postage batch with low amount, uploads data, waits for the batch to expire, then asserts the batch is unusable and new uploads are rejected
track reserve state before and after batch purchase, and after expiry+GC poll for radius decrease when the reserve is small enough to have forced a radius increase
| postage-depth: 17 | ||
| postage-topup-amount: 100 | ||
| postage-new-depth: 18 | ||
| ci-stamp-expiry: |
There was a problem hiding this comment.
Better thing would be that we are spinning this kind of tests, on public testnet, as part of checks that are executed once for every RC.
| // Options represents check options | ||
| type Options struct { | ||
| FileSize int64 | ||
| PostageAmount int64 |
There was a problem hiding this comment.
Other checks are using PostageTTL option, where you could set 24h as minimum postage validtity.
| return fmt.Errorf("no nodes in cluster") | ||
| } | ||
|
|
||
| uploadNode := sortedNodes[0] |
There was a problem hiding this comment.
Prefarable option with beekeper checks is to use radnom cluster node, instead of always using the same one. This can be achieved calling cluster.ShuffledFullNodeClients(ctx, random.PseudoGenerator(time.Now().UnixNano())) which returns random list of bee nodes.
| } | ||
| c.logger.Infof("node %s: created batch %s", uploadNode, batchID) | ||
|
|
||
| // Verify batch exists and is usable |
There was a problem hiding this comment.
There is a minimum of 10 block to wait for the batch to be usable. This would require some wait time.
|
@gacevicljubisa totally ok with infrequent tests but would be good to have regular data and be able to a/b candidate versions! thanks for your comments! |
2 participants
new integration check that buys a postage batch with low amount, uploads data, waits for the batch to expire, then asserts the batch is unusable and new uploads are rejected