feat(message): add universal pagination contract with cursor support for MSTeams#100858
feat(message): add universal pagination contract with cursor support for MSTeams#100858wm0018 wants to merge 2 commits into
Conversation
4c40b30 to
6272b23
Compare
6272b23 to
62c51ae
Compare
|
@clawsweeper review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
Codex review: needs real behavior proof before merge. Reviewed July 6, 2026, 9:15 PM ET / 01:15 UTC. Summary PR surface: Source +296, Tests +25, Docs 0. Total +321 across 14 files. Reproducibility: yes. at source level. The current PR head still registers Review metrics: 2 noteworthy metrics.
Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Maintainer decision needed
Security Review findings
Review detailsBest possible solution: Define the shared message pagination contract intentionally, then merge only CLI/provider cursor paths whose first-page and next-page behavior are wired and proven with redacted live MSTeams evidence. Do we have a high-confidence way to reproduce the issue? Yes, at source level. The current PR head still registers Is this the best way to solve the issue? No. The direction is plausible, but it is not the best mergeable solution until maintainers accept the shared contract and every advertised cursor path is either wired end-to-end or removed from the rollout. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against cb0d8a1294ea. Label changesLabel justifications:
Evidence reviewedPR surface: Source +296, Tests +25, Docs 0. Total +321 across 14 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (4 earlier review cycles)
|
62c51ae to
c1f4ddf
Compare
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
c1f4ddf to
08cbf01
Compare
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
…for MSTeams - Add MessageActionPagination type (hasMore, nextCursor) to shared result shape - Add extractPagination() to normalize from channel-private _pagination key - Refactor renderPaginationHint to read result.pagination with legacy renderPayloadPaginationHint fallback for unmigrated providers - Restore Discord total_results-vs-count pagination hint as three-stage fallback - Add --cursor CLI flag to read, pins, search commands - Surface pagination in --json output via buildMessageCliJson - MSTeams: add listMessagesMSTeams for batch read with cursor pagination - MSTeams: refactor read handler — messageId reads single, otherwise batch list - MSTeams: wire search/list-pins nextCursor for external cursor pagination - MSTeams: validate cursor URLs against known Graph API origins before auth - Update docs/cli/message.md with --cursor flag references Refs openclaw#71452
08cbf01 to
f7d9d41
Compare
|
This pull request has been automatically marked as stale due to inactivity. |
What Problem This Solves
Partially addresses #71452 — provides the shared pagination contract and CLI cursor support, and wires MSTeams search, read, list-pins, and channel-list as the first provider implementation.
Previously,
renderPaginationHintinspected provider-specific raw payload fields (hasMore,nextBatch,@odata.nextLink,total_results) with no shared contract. Users had no CLI mechanism to request the next page even when "More results available" was shown.Why This Change Was Made
Introduces a universal cursor-based pagination model across the shared runner, formatter, and CLI layers. Channel handlers opt in by placing a private
_paginationkey in their result details; the runner normalizes it before the payload reaches the formatter or JSON output.Architecture
Key decisions
nextCursorstring: channels produce whatever token their API uses (nextLink URL, offset number, batch token). The CLI and formatter never parse it._paginationkey: zero SDK changes. Channels opt in voluntarily. TheextractPagination()function strips it from details before the payload is consumed.--cursorCLI flag onread,pins,search— all three wired end-to-end for MSTeams.searchMessagesMSTeamsandlistMessagesMSTeamsvalidate cursor URLs against known Microsoft Graph API origins (v1.0,beta) before resolving any auth token — invalid origins never carry credentials.renderPayloadPaginationHintpreserves existing payload-based hints for providers not yet migrated. Discordtotal_results-vs-count comparison remains as a three-stage fallback chain.User Impact
MSTeams users can now paginate all three list-producing actions:
searchsearchMessagesMSTeamsvia@odata.nextLinkURLreadlistMessagesMSTeams(new) — no--message-id= list modepinslistPinsMSTeamsexposes@odata.nextLinkwhen page limit reachedEvidence
Real CLI output (production
formatMessageCliTextcode path)Cursor URL validation (production code path, before auth token)
https://graph.microsoft.com/v1.0/...andhttps://graph.microsoft.com/beta/...requireValidCursorOriginruns insearchMessagesMSTeamsandlistMessagesMSTeamsbeforeresolveGraphToken, so invalid URLs never carry credentialsTests
CI
Files Changed (14 files, +405/-84)
Follow-up
If the contract shape is accepted, subsequent PRs will wire pagination for: