payments: count total with date filters

[0xjc65eth]

Summary

• Make QueryPayments TotalCount honor CreationDateStart and CreationDateEnd when CountTotal is requested.
• Keep the existing complete/incomplete count semantics unchanged.
• Apply the fix to both KV and SQL backends, including sqlc query metadata.
• Add a TestQueryPayments case where pagination returns 2 payments but TotalCount reports the 3 payments in the date window.
• Add a release note entry for the ListPayments count fix.

Fixes #8530.

Tests

• go test ./payments/db -run TestQueryPayments -count=1
• go test -tags test_db_sqlite ./payments/db -run TestQueryPayments -count=1
• (cd sqldb && go test ./sqlc -count=1)

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request ensures that the TotalCount field in payment queries accurately reflects the date-filtered results. By applying consistent filtering logic across both KV and SQL backends, the system now correctly reports the total number of payments within a specified time range, even when pagination is applied to the result set.

Highlights

• Payment Filtering: Updated the QueryPayments total count logic to respect CreationDateStart and CreationDateEnd filters.
• Backend Support: Implemented the filtered count logic for both KV and SQL storage backends, including new sqlc query definitions.
• Testing: Added a new test case in TestQueryPayments to verify that TotalCount correctly reflects the number of payments within a specific date window.

New Features

🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces support for counting total payments with date filters in both the KV and SQL database backends. In the KV store, a new matchesCreationDate helper is used to filter payments, and countFn is updated to apply these filters when counting total payments. In the SQL store, a new CountFilteredPayments query is added to perform the filtered count. However, feedback highlights a performance issue in the KV store implementation: calling fetchPaymentWithSequenceNumber inside countFn for every payment is highly inefficient as it fully deserializes the entire payment and its HTLC attempts. It is recommended to optimize this by only fetching the creation time.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[github-actions]

PR Severity: HIGH. sqldb/* files (querier.go, payments.sql) drive HIGH classification. payments/* files are MEDIUM. 4 non-excluded files, ~120 non-excluded lines. No bump triggered. <!-- pr-severity-bot -->

[0xjc65eth]

Thanks for the review. I updated the KV counting path so date-filtered CountTotal no longer calls fetchPaymentWithSequenceNumber. It now uses a lightweight fetchCreationTimeWithSequenceNumber helper that only reads PaymentCreationInfo for the matching sequence number, including legacy duplicate-payment buckets, and avoids loading/deserializing HTLC attempts.\n\nI also added the release note entry and refreshed the PR body.\n\nRe-ran:\n- go test ./payments/db -run TestQueryPayments -count=1\n- go test -tags test_db_sqlite ./payments/db -run TestQueryPayments -count=1\n- (cd sqldb && go test ./sqlc -count=1)