Files
psf-memo/psf-memo-db/specs/efficient-post-pagination.feature
T
Chris Troutner 2bcc965efb Review feed-query-performance: remove dead full-scan methods, harden mutation coverage
Remove the full-scan methods the capped-scan optimization replaced
(topLevelPostTxids, countTopLevelPosts, countTopLevelPostsByAddr,
buildReplyCountMap) and their tests, keeping the backwards-compat wrappers.
Add hardening tests to kill 4 mutation survivors (raw scan bound, viewerAddr
fallback). Refresh mutation manifests and Gherkin acceptance-mutation stamps.

By architect.
2026-09-04 18:59:27 -07:00

49 lines
3.4 KiB
Gherkin

# acceptance-mutation-manifest-begin
# {"version":1,"tested_at":"2026-09-05T01:57:34.656990218Z","feature_name":"Efficient post pagination","feature_path":"/home/trout/work/psf-memo/.worktrees/architect/psf-memo-db/specs/efficient-post-pagination.feature","background_hash":"09cc76dccab8b5ac80dd4f72dfbca640087c6bd80ed29d9b9687a41fa20a038f","implementation_hash":"unknown","scenarios":[{"index":1,"name":"Efficient post pagination - 2 GET /posts/by/:addr returns a page of top-level posts for that address sorted by block height descending","scenario_hash":"1d87e78064f9c2b2f227b4cc405e2ea898b15ab34dc245a97f205a8edf1cc8fc","mutation_count":18,"result":{"Total":18,"Killed":18,"Survived":0,"Errors":0},"tested_at":"2026-08-26T18:23:09.918773322Z"}]}
# acceptance-mutation-manifest-end
# Scenarios: Efficient post pagination - 1, Efficient post pagination - 2, Efficient post pagination - 3
Feature: Efficient post pagination
Background:
Given a psf-memo-db instance with a posts store and a postHeights secondary index
Given the fixture "three-top-level-posts-and-one-reply" is loaded into the posts store
Scenario Outline: Efficient post pagination - 1 GET /posts/recent returns a page of top-level posts sorted by block height descending
When the client requests /posts/recent with limit <limit> and offset <offset>
Then the response posts are sorted by block height descending
And the response contains the txids <expected_txids>
And the response pagination shows total <total> and hasMore <hasMore>
And no more than <limit> postHeights entries are read after applying the offset
And no more than <limit> posts are loaded by txid
Examples:
| limit | offset | expected_txids | total | hasMore |
| 2 | 0 | post-200-b,post-200-a | 3 | true |
| 2 | 1 | post-200-a,post-100 | 3 | false |
| 3 | 0 | post-200-b,post-200-a,post-100 | 3 | false |
Scenario Outline: Efficient post pagination - 2 GET /posts/by/:addr returns a page of top-level posts for that address sorted by block height descending
When the client requests /posts/by/<addr> with limit <limit> and offset <offset>
Then the response posts are sorted by block height descending
And the response contains only posts by <addr>
And the response contains the txids <expected_txids>
And the response pagination shows total <total> and hasMore <hasMore>
Examples:
| addr | limit | offset | expected_txids | total | hasMore |
| bitcoincash:qaddr-a | 1 | 0 | post-200-a | 2 | true |
| bitcoincash:qaddr-a | 2 | 0 | post-200-a,post-100 | 2 | false |
| bitcoincash:qaddr-b | 1 | 0 | post-200-b | 1 | false |
Scenario Outline: Efficient post pagination - 3 reply counts are computed per returned post
When the client requests /posts/recent with limit <limit> and offset <offset>
Then the response post with txid <txid> has replyCount <replyCount>
And the postChildren store was iterated at most <max_iterations> times
Examples:
| limit | offset | txid | replyCount | max_iterations |
| 3 | 0 | post-200-a | 1 | 3 |
| 3 | 0 | post-200-b | 0 | 3 |
| 3 | 0 | post-100 | 0 | 3 |