Fix pagination in x:MaskedEmail/query

StefanSa commented

2026-11-05 19:23:16 +00:00

While integrating Inbuxa's native MaskedEmail API into Bulwark Webmail, we found a pagination issue in x:MaskedEmail/query.

Problem

A query using a positive position can return IDs from the first page again, while the requested limit is not applied correctly.

This results in duplicate entries and unreliable pagination for clients using the native MaskedEmail API.

Root cause

extract_parameters(..., Some(Property::Id)) consumes the pagination parameters before QueryResponseBuilder can process them.

Proposed fix

Use the existing in-memory query path with None instead, allowing QueryResponseBuilder to handle pagination correctly.

The change is small and limited to the affected query path.

Validation

Added a focused regression test covering:

Positions 0, 1 and 2
Limit of one result per page
Correct ordering without duplicate IDs

Results:

New regression test: PASS
Existing MaskedEmail tests: PASS
SQLite: 2 passed, 0 failed
Formatting and git diff --check: PASS

Patch

The attached masked-email-pagination.patch contains the fix and regression test, prepared against upstream main using git format-patch.

Related Bulwark contributions

Thanks for taking a look!

Stefan

While integrating Inbuxa's native MaskedEmail API into Bulwark Webmail, we found a pagination issue in `x:MaskedEmail/query`. **Problem** A query using a positive `position` can return IDs from the first page again, while the requested `limit` is not applied correctly. This results in duplicate entries and unreliable pagination for clients using the native MaskedEmail API. **Root cause** `extract_parameters(..., Some(Property::Id))` consumes the pagination parameters before `QueryResponseBuilder` can process them. **Proposed fix** Use the existing in-memory query path with `None` instead, allowing `QueryResponseBuilder` to handle pagination correctly. The change is small and limited to the affected query path. **Validation** Added a focused regression test covering: - Positions 0, 1 and 2 - Limit of one result per page - Correct ordering without duplicate IDs Results: - New regression test: PASS - Existing MaskedEmail tests: PASS - SQLite: 2 passed, 0 failed - Formatting and `git diff --check`: PASS **Patch** The attached `masked-email-pagination.patch` contains the fix and regression test, prepared against upstream `main` using `git format-patch`. **Related Bulwark contributions** - [[PR #1522 – Inbuxa account security management](https://github.com/bulwarkmail/webmail/pull/1522)](https://github.com/bulwarkmail/webmail/pull/1522) - [[PR #1534 – Native Masked Address management](https://github.com/bulwarkmail/webmail/pull/1534)](https://github.com/bulwarkmail/webmail/pull/1534) Thanks for taking a look! Stefan

masked-email-pagination.patch

3.3 KiB

jcoffey-dev added the bug

priority

p2

labels 2026-11-06 06:37:46 +00:00

jcoffey-dev self-assigned this 2026-11-06 06:37:46 +00:00

jcoffey-dev referenced a pull request that will close this issue

2026-11-06 06:56:47 +00:00

Query paging for masked email and archived items #297

jcoffey-dev commented

2026-11-06 06:57:27 +00:00

Owner

Thanks Stefan, good find. This is up as #297 with your commit under your name. The archived items query (x:ArchivedItem/query) had the same bug, so there's a second commit that fixes it the same way and adds a paging check to the undelete test. Your new test and the existing masked email tests pass here.

Thanks Stefan, good find. This is up as #297 with your commit under your name. The archived items query (`x:ArchivedItem/query`) had the same bug, so there's a second commit that fixes it the same way and adds a paging check to the undelete test. Your new test and the existing masked email tests pass here.

jcoffey-dev closed this issue

2026-11-06 07:08:38 +00:00

jcoffey-dev commented

2026-11-06 07:09:11 +00:00

Owner

Merged in #297, so it will be in 27.1-rc.9. Thanks again Stefan.

Fix pagination in x:MaskedEmail/query #296