fix(memory/sync): send fetch_type in Notion NOTION_FETCH_DATA args

[YellowSnnowmann]

Summary

Composio's NOTION_FETCH_DATA action now requires a fetch_type field. The memory-sync Notion provider's arguments() never sent it, so every periodic Notion memory sync failed with Following fields are missing: {'fetch_type'}.

This adds "fetch_type": "pages" to the sync provider's request args. It's unconditional because this path hardcodes filter: {value: "page"}, so "pages" is the only valid value (the agent-tool path's inference logic is deliberately not duplicated here).

The agent-tool path in OpenHuman already handles this via ensure_notion_fetch_type; only this memory-sync path was still missing the field.

Fixes tinyhumansai/openhuman#5506.

API Or Behavior Changes

None — internal request-args shape only. Adds a field the upstream Composio API now requires.

Tests

• cargo fmt --check
• cargo clippy --all-targets -- -D warnings
• cargo build --all-targets
• cargo test — 1396 tests, 0 failed

Added a body_partial_json matcher on the NOTION_FETCH_DATA mock in tests/composio_sync_mock.rs asserting the outgoing request carries fetch_type: "pages" (fails pre-fix), following the existing Slack/ClickUp request-body matcher pattern in the same file.

Documentation

None needed — internal provider request shape.

Summary by CodeRabbit

• Bug Fixes
  • Improved Notion page synchronization by explicitly requesting page data during fetches.
  • Preserved existing pagination, filtering, and sorting behavior.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e85d66b6-7606-498f-8027-c32681d7d67e

📥 Commits

Reviewing files that changed from the base of the PR and between 4f6517c and b9b38fc.

📒 Files selected for processing (2)

• src/memory/sync/composio/providers/notion.rs
• tests/composio_sync_mock.rs

---

📝 Walkthrough

Walkthrough

The Notion memory sync request now includes fetch_type: "pages". The Composio sync mock validates that the request includes this required argument.

Changes

Notion memory sync

Layer / File(s)	Summary
Notion request and mock validation src/memory/sync/composio/providers/notion.rs, tests/composio_sync_mock.rs	The Notion fetch request adds fetch_type: "pages". The mock requires the same value.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Mergeability Score: ⚪ Minimal · up to b9b38

The Notion memory-sync request now includes the required page fetch type, restoring compatibility without changing public APIs, permissions, data scope, or deployment behavior; no actionable merge-blocking risk remains after normal checks and review.

Suggested reviewers: senamakel

Poem

I’m a rabbit with pages to fetch,
A missing field now passes the check.
The sync hops along,
With mock guards strong,
And Notion requests are in spec! 🐇

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Linked Issues check	⚠️ Warning	The PR adds and tests fetch_type for tinycortex, but provides no task-source audit or evidence that the submodule pointer was bumped [#5506].	Audit and patch the task-source path if required, and include the updated tinycortex submodule pointer.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: adding fetch_type to Notion NOTION_FETCH_DATA arguments.
Out of Scope Changes check	✅ Passed	The provider change and mock validation directly support the linked issue and contain no unrelated code changes.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[tinysweeper]

What this change touches

2 files, +4 -1 across 2 components. The code graph knows nothing about these files yet — normal for newly added files, and a cold index otherwise.

flowchart LR
  n0["tests<br/>1 file +3 -0"]:::changed
  n1["src/memory/sync/composio/providers<br/>1 file +1 -1"]:::changed
  classDef changed fill:#0d4429,stroke:#238636,color:#e6edf3
  classDef impacted fill:#161b22,stroke:#6e7681,color:#c9d1d9
  classDef flagged fill:#5a1e02,stroke:#d93f0b,color:#ffffff
  classDef blocking fill:#67060c,stroke:#f85149,color:#ffffff

Loading

_{Green: changed. Grey: untouched, reached through an import or a call. Orange: has findings. Red: has a finding that blocks the merge.}

Component		Files	Lines	Findings
tests	changed	1	+3 -0	—
src/memory/sync/composio/providers	changed	1	+1 -1	—

Changed files

tests

• tests/composio_sync_mock.rs

src/memory/sync/composio/providers

• src/memory/sync/composio/providers/notion.rs

[tinysweeper]

tinysweeper found nothing blocking. Approving.

             $0.0077 · 10,747 in / 2,186 out · 9,038 cached (84%) · z-ai/glm-5.2
critique:    $0.0040 · 3,138 in  / 1,395 out · 2,765 cached (88%) · z-ai/glm-5.2
security:    $0.0011 · 3,096 in  / 203 out   · 2,729 cached (88%) · z-ai/glm-5.2
tests:       $0.0010 · 1,664 in  / 215 out   · 1,222 cached (73%) · z-ai/glm-5.2
description: $0.0006 · 2,004 in  / 82 out    · 1,726 cached (86%) · z-ai/glm-5.2

[oxoxDev]

Approving. Adds the now-required fetch_type: "pages" to the only NOTION_FETCH_DATA producer in this repo, and the value is consistent both with this path's hardcoded filter: {value: "page", property: "object"} and with openhuman's ensure_notion_fetch_type, which infers "pages" from exactly that filter.

The test is genuine, not tautological — I checked by experiment rather than by reading. Removing only the fetch_type token from tests/composio_sync_mock.rs:493-497 on a merged checkout makes notion_fetches_markdown_and_counts_both_requests panic with Composio direct request failed with HTTP 404. The chain is wiremock no-match → 404 → execute_direct bails (client.rs:168) → IncrementalSource::tolerate_scope_errors() defaults false (orchestrator.rs:63) → tick().unwrap() panics. So it is a real request-body assertion that would fail against pre-fix code.

Two notes, neither blocking:

• notion.rs:74 is confirmed the sole call site in tinycortex (grep -rn NOTION src/ tests/ turns up only the ACTION_FETCH/ACTION_MARKDOWN consts). The other paths in #5506 are out of reach from here: the agent-tool path is already fixed at src/openhuman/integrations/composio/execute_prepare.rs:70, but AC item 4 (the fetch_tasks task-source path) I could not verify — gh search code finds no NOTION_FETCH_DATA outside execute_prepare.rs and tests, and the .../providers/notion/provider.rs referenced in the issue 404s. Worth auditing before closing #5506, since this PR alone doesn't satisfy it.
• The literal is unconditional, so if a scope ever queries databases rather than pages, fetch_type will need to move next to the filter construction. Already called out in the PR body and fine as-is.

Nit: a body-matcher miss surfaces as an opaque HTTP 404 rather than "body mismatch", which cost a minute to trace — but that matches the existing Slack/ClickUp pattern in this file, so no change requested.

Merge-order note: #146 depends on this one. Without fetch_type every NOTION_FETCH_DATA request is rejected, so #146's render_properties never executes in production. This should land first.