testing: complex useTransactionHistory hook has no test coverage

[Ejirowebfi]

Summary

useTransactionHistory contains the app's most intricate client logic (cursor pagination, in-memory cache, debounced refetch, operation parsing) yet has no test file, while simpler utilities are well covered.

Evidence

• No useTransactionHistory.test.* exists under frontend/src.
• The hook has multiple latent bugs (see related issues: hardcoded network, broken pagination, filter-blind cache) that tests would have caught.

Suggested fix

Add unit tests with a mocked Horizon response covering: network selection, multi-page loadMore with cursors, cache hits/misses across filter changes, and parseOperation mapping for create/mint/burn. This pairs naturally with fixing the related bugs.

[Emmanuellsensai]

Hi, I'd like to take this. Adding coverage to useTransactionHistory makes sense given it holds the most complex client logic in the app and currently has no test file.

Plan:

• Set up Vitest plus Testing Library with a mocked Horizon response (mocking fetch) so the hook can be driven deterministically.
• Cover the cases listed: network selection, multi-page loadMore with cursor/paging_token passing, cache hits and misses across filter changes, and parseOperation mapping for create, mint, and burn.
• Write the assertions against correct expected behavior. Since the issue notes latent bugs (hardcoded network, broken pagination, filter-blind cache), I'll flag any test that exposes a real bug rather than quietly matching current output, so the suite documents the defect instead of locking it in.
• Keep mocks realistic to actual Horizon operation payloads so the tests stay meaningful.

I'll match the repo's existing test patterns and keep the change scoped to the new useTransactionHistory.test file plus any minimal test helpers. I'll wait for assignment before opening a PR.

[Emmanuelluxury]

Hi maintainer,

I would like to work on this issue.

From my understanding, the goal is to replace the compile-time HISTORY_MAX_DEPTH constant with an admin-configurable on-chain value while enforcing a hard upper bound at the contract level. This will allow LedgerLens to adjust history retention requirements without requiring contract redeployment, while preserving predictable storage costs and maintaining compatibility with existing integrations.

I have experience working with Rust smart contracts, storage-driven configuration patterns, and state management in blockchain applications. I am comfortable implementing configurable contract parameters, validation logic, and storage-backed settings while ensuring behavior remains deterministic and well-tested.

If assigned, I will:

• Review the current history storage implementation and trace how HISTORY_MAX_DEPTH is used throughout the score history lifecycle

• Replace the existing compile-time depth constant with the proposed MAX_HISTORY_DEPTH and DEFAULT_HISTORY_MAX_DEPTH constants

• Add the new HistoryMaxDepth storage key to DataKey and implement storage helpers for retrieving and persisting the configured depth

• Update push_score_history to use the configured depth from contract storage rather than a compile-time value

• Implement set_history_max_depth with proper admin authorization and validation to reject zero values and values exceeding the configured ceiling

• Implement get_history_max_depth to expose the current configured value while correctly falling back to the default when no configuration exists

• Add the new InvalidHistoryDepth error and ensure validation failures return the appropriate contract error

• Carefully implement and verify the lazy-truncation behavior when history depth is reduced, ensuring existing entries remain intact until the next submit_score operation triggers the eviction logic

• Add comprehensive Rustdoc documentation explaining the depth configuration behavior and explicitly documenting the lazy-truncation edge case

• Update the README to include both configuration functions and their intended usage

• Add and validate all required test cases covering default values, depth increases, depth decreases, ceiling enforcement, invalid depth handling, and lazy-truncation behavior

• Verify that storage usage remains bounded by the hard ceiling and that the configurable depth integrates cleanly with the existing ring-buffer implementation

I will also ensure the implementation remains consistent with existing Soroban storage patterns, keeps function signatures clean, and avoids introducing unnecessary coupling throughout the history management code.

Kindly assign this issue to me. Thank you!

[Yasir-TechGuy]

Hi Maintainer,

I'd like to work on this issue because testing complex client-side logic is one of the most effective ways to prevent regressions and uncover edge cases early. I have experience writing unit tests for React hooks, pagination workflows, caching behavior, and API integrations. I'm confident in delivering comprehensive test coverage for useTransactionHistory and validating the critical scenarios outlined in the issue.

Please assign this issue to me.

[grantfox-oss]

🦊 GrantFox — @Emmanuelluxury has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #853)
2. Your PR will be reviewed by the Favourorg maintainers

Good luck! Track your progress on GrantFox.