Ownership chain lookups are not paginated

[mftee]

A document with a long ownership history returns its entire chain in a single response from module/ownership_chain, with no pagination.

[jarik2014]

@jarik2014 has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

can i take this one? the helper is already there — contract/src/module/ownership_chain/pagination.rs has paginate() and Page{items,next_cursor}, but nothing calls it and GET /verify/:hash/history returns the whole Vec. i'd wire the cursor param in. one question before i push: do you want the paginated envelope always, or only when the caller passes cursor/page_size? asking because it changes the response shape for existing clients.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @jarik2014 to this issue.

[jarik2014]

PR #1423 is up for this one. Short version of what was actually missing: pagination.rs had a working paginate(), but mod.rs never declared the module and nothing called it — so the fix is the wire. I connected cursor/page_size to GET /verify/:hash/history (that is the chain endpoint the router in lib.rs actually mounts; GET /transfer/:document_hash exists in routes.rs but is never added to app(), so paginating that handler would have changed nothing). It is opt-in: no params means the old response exactly, plus next_cursor. 12 tests (7 unit + 5 integration), and contract/ did not compile on main at all, so the first commit carries the unbreak (chrono serde, Arc rate limiter, the moved data_key in the mocks) without which no test can run.

Could you assign this issue to me in Drips? I applied for it, and the wave only credits an assigned applicant — a merge alone leaves it at pointsEarned: null.

[jarik2014]

PR #1423 was closed without a note, and I would rather fix my part than guess. Was it the scope (I carried a first commit that unbreaks contract/ — chrono's serde feature, the Arc-wrapped rate limiter, the moved data_key in the mocks — because the crate does not compile on main at all, so no test can run) or the approach (paging GET /verify/:hash/history, since get_transfer_history is not mounted by the router in lib.rs)? Tell me which and I will rework it: I can drop the unbreak into its own PR, move the pagination to the handler you prefer, or leave it. The tests are green on the merged revision (7 unit + 5 integration, 19/19 in the integration target).

[jarik2014]

Re-opened as a fresh PR (#1424) after #1423 was closed — and this one is smaller and, I think, closer to what you want.

The pagination module from #1401 is in main but nothing calls it: it is not declared in its own mod.rs, Page<T> is not serializable, and no handler uses it. So the endpoint kept returning the whole chain. The new PR wires it (?cursor= / ?page_size=, with total and next_cursor in the response), hardens paginate against a cursor past the end and a zero page size, and moves the page-size policy (default 50, cap 200) into the module so both handlers share it.

Two things you should know while reviewing:

1. The crate does not compile on main — cargo check fails on five errors (chrono without its serde feature while Event derives serde over DateTime<Utc>; AppState deriving Clone while holding a governor RateLimiter) and the test targets had never been compiled at all (tower without util, so no oneshot resolves). That is the PR's first commit, split out so it can be reviewed separately; without it no test of this issue can even run.
2. There are two app() functions and two copies of verify_document_history — one pair in src/lib.rs, another in src/routes.rs + src/handlers/verify.rs. The binary and the tests use the lib.rs pair, which I only discovered because paginating the handlers/ copy alone changed nothing. Both are kept in step in the PR; consolidating them is a separate job.

cargo test --test handler_integration_tests history → 4 passed; cargo test --lib pagination → 7 passed. Could you assign this issue to me in Drips? The wave only credits the assigned applicant.

[lynaDev2]

@lynaDev2 has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

can i work on this

ℹ️ Repo Maintainers: To accept this application, review their application or assign @lynaDev2 to this issue.

[drips-wave]

Congratulations, @lynaDev2! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on September 30, 2026.

🧑‍💻 @lynaDev2: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[drips-wave]

This issue has been completed by @lynaDev2 as part of the Stellar Wave Program's 9th Wave 🥳

😎 @lynaDev2: You earned 200 Points for completing this issue! After the current Wave ends, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here. You can also Leave a review to share your experience working on this issue.

🧑‍💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.