fix(entries): correct merged-timeline pagination on includeLinkedPersons#64
Merged
Conversation
Two off-by-one-class bugs in the v1.6.6 fan-out merge path:
1. Under-fetch for page > 1 — only `perPage` candidates were pulled
per linked party, so page 2 sliced from too small a pool and
could come back short/empty.
2. False end-of-feed on an exactly-full page 1 — nextPage was
`merged.length > start + perPage`, which reported undefined when
the page filled exactly perPage even though linked parties still
had older entries upstream (the per-party Link rel=next was
discarded).
Fix: fetch min(page × perPage, 100) candidates per party
(mergedTimelineCandidatePerParty), and preserve each party's upstream
next-page signal when the requested window fits within the per-party
fetch cap (mergedTimelineNextPage). fanOutPartyEntries now returns
{entries, nextPage} per party so the signal is available. Very deep
pagination on a large multi-person org can still be approximate
(documented). Default single-GET path unchanged.
Cherry-picked from the substantive part of codex PR #62, dropping
that PR's v1.6.6→v1.7.0 doc rewrites and the wire-trace-v166→v170
rename — the probe scripts are iteration markers (v163–v167), not
release versions, and renaming only v166 would break the sequence
and the NOTES §32 references. The release-version bump is a
release-cut decision, deferred.
537 tests (+1). Bundle 168.08 KB stdio / 195.95 KB http.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This was referenced May 29, 2026
arapov
added a commit
that referenced
this pull request
May 29, 2026
#67) Cherry-picked the genuine bits from codex PR #66, dropping that PR's v1.6.6→v1.7.0 doc rewrites and the wire-trace-v166/v167→v170-* probe renames (iteration markers, not release versions — rejected the same way as #62/#64). Real fixes the audit's docs lane missed: - README.md tool table: Tags row now lists delete_tag_definition (was added to the catalog but not the README table). - src/capsule/cache.ts: header + invalidateByPrefix doc comments now name delete_tag_definition as a third tag-mutating tool that drops the list_tags cache (accurate — the handler does call invalidateByPrefix), and generalize "/tags" → "/<entity>/tags". Test coverage: - tests/cache.test.ts: delete_tag_definition invalidates the cached list_tags response. - tests/entries.test.ts: a merged-timeline window that CROSSES the 100-entry ceiling returns the in-ceiling tail and ends the feed (complements the #65 boundary test with the partial-window case). Plus a sharper PAGINATION CAVEAT wording (distinguishes crossing-window truncation from beyond-ceiling empty) — kept the v1.6.6 provenance. Closes #66 (cherry-picked clean). 538 → 540 tests. Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes two real pagination bugs in the v1.6.6
list_party_entriesfan-out merge (theincludeLinkedPersonspath):page > 1— onlyperPagecandidates were pulled per linked party, so a second page sliced from too small a pool and could come back short or empty.nextPagewasmerged.length > start + perPage, which reportedundefinedwhen the page filled exactlyperPageeven though linked parties still had older entries upstream (each party'sLink rel=nextwas discarded). Callers stopped paging early.Fix: fetch
min(page × perPage, 100)candidates per party (mergedTimelineCandidatePerParty), and preserve each party's upstream next-page signal when the requested window fits within the per-party fetch cap (mergedTimelineNextPage).fanOutPartyEntriesnow returns{entries, nextPage}per party so the signal survives the merge. Very deep pagination on a large multi-person org can still be approximate (documented on the schema). The default (includeLinkedPersonsomitted) single-GET path is bit-for-bit unchanged.Provenance — cherry-picked from #62, churn dropped
The substantive fix comes from codex's #62. I took the
entries.ts+entries.test.tschanges and dropped two things that PR also did:v1.6.6 → v1.7.0text rewrites — the probe scripts are iteration markers (v163–v167), not release versions. The v166 probe verified this behaviour during the v1.6.6-era work; relabeling it "v1.7.0" makes the historical record false.wire-trace-v166.ts → wire-trace-v170.tsrename — renaming only v166 (while v167 keeps its name) breaks the sequence and the NOTES §32 references.#62 also correctly noted the next release should be a minor bump (new tools) — that's a release-cut decision, deferred to the cut rather than baked into
[Unreleased]doc text now.Closes #62 (cherry-picked clean).
Test plan
entries.test.tscovers: under-fetch fixed for page 2, exactly-full page 1 preserves nextPage via upstream Link, deep-page approximation documentedincludeLinkedPersonscanary still passes)🤖 Generated with Claude Code