You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Notion needs someone with a real workspace to run its test #215
The Notion source ships with parsing tests only. Nobody has pointed it at a real workspace.
Unlike the other connectors there is no way to close this locally: Notion is closed-source SaaS
with no emulator, and the open-source alternatives (AppFlowy, AFFiNE) do not speak its API.
The risk is the same one that bit S3, which passed its construction tests and still broke on
every bucket with a folder in it until a live endpoint was tried.
What would help: create an internal integration, share one page with it, run the test.
# Settings -> My connections -> New internal integration# then share a page with it from the page's ... menu
UTOPIA_NOTION_TEST_TOKEN=ntn_xxx cargo test -p utopia-server notion
A free workspace with a single page works. The token is read-only over exactly the pages you
share with it.
The parts most likely to be wrong, none of which construction tests reach:
Pagination. Both /v1/search and /v1/blocks/{id}/children page at 100. A workspace with
more than that exercises has_more and next_cursor; one with fewer never does.
Notion-Version. Pinned to 2026-03-11. A wrong value returns 400 saying only "missing
version", without naming an acceptable one.
Database rows. Their title property is named by the user, so the by-type lookup matters
here in a way it does not for plain pages.
Rate limiting. Roughly three requests a second. Requests are sequential for that reason,
but nobody has watched what a workspace large enough to hit it actually does.
The command in the description is all it needs, and a free workspace with one shared page is enough. What's most useful back: whether the sync produces one document per page, whether Notion-Version: 2026-03-11 is still accepted, and — if your workspace has more than 100 pages, or a page with more than 100 blocks — whether pagination holds. Paste any error verbatim; the client surfaces Notion's own message.
A comment with what happened closes this. No PR needed unless you find something to fix. Much appreciated.
That is exactly what was needed, thank you. The small workspace answers the open question: the connector works against a real workspace and the pinned Notion-Version is still accepted.
The large one found a real bug. Fetching is sequential, but sequential at full speed is still well above Notion's three requests per second, and the client treats a 429 as fatal instead of waiting out the Retry-After header. I'll fix that here (honour Retry-After, pace requests) and mention you in the PR. If you can run the same command once more after it lands, that would close the loop on pagination too, since your large workspace is the only one we have that exercises it.
Also noted: that error message leaked a Chinese word into your terminal. It will be English.
The fix is on dev as of #269 (f366693): requests are paced at 350 ms and a 429 waits out Retry-After instead of ending the sync. @jeremycapps, when you have a moment:
git fetch origin dev && git checkout origin/dev
UTOPIA_NOTION_TEST_TOKEN=ntn_xxx cargo test -p utopia-server notion
The large workspace is the interesting one. It should now take a few minutes rather than fail; if it passes, that also confirms pagination past 100 pages and 100 blocks, and I'll close this with your result as the record.
That closes it — thank you. Between your two runs this issue got everything it asked for: the small workspace confirmed the connector works against a real one and that Notion-Version: 2026-03-11 is still accepted; the large one found that a 429 was being treated as fatal, and now that it passes, it also confirms pagination past 100 pages and 100 blocks — which nothing on our side could reach without a workspace like yours.
#269 is the fix your first run produced. The Chinese line that showed up in your terminal is gone as well: it was the last one left on that path, and it went out in #420.
Closing with your result as the record. Thanks especially for coming back two days later for the rerun — that second run is why this can be closed on evidence rather than left open on a hunch.
Activity
jeremycapps commentedon Sep 3, 2026
Hey, I'll take this one. @WaylandYang
WaylandYang commentedon Sep 3, 2026
Thanks for picking this up — it's yours.
The command in the description is all it needs, and a free workspace with one shared page is enough. What's most useful back: whether the sync produces one document per page, whether
Notion-Version: 2026-03-11is still accepted, and — if your workspace has more than 100 pages, or a page with more than 100 blocks — whether pagination holds. Paste any error verbatim; the client surfaces Notion's own message.A comment with what happened closes this. No PR needed unless you find something to fix. Much appreciated.
jeremycapps commentedon Sep 3, 2026
Output from a small workspace <100 pages/blocks.

Output from a large workspace > 100 pages/blocks. I got a rate limiting error.
WaylandYang commentedon Sep 3, 2026
That is exactly what was needed, thank you. The small workspace answers the open question: the connector works against a real workspace and the pinned Notion-Version is still accepted.
The large one found a real bug. Fetching is sequential, but sequential at full speed is still well above Notion's three requests per second, and the client treats a 429 as fatal instead of waiting out the Retry-After header. I'll fix that here (honour Retry-After, pace requests) and mention you in the PR. If you can run the same command once more after it lands, that would close the loop on pagination too, since your large workspace is the only one we have that exercises it.
Also noted: that error message leaked a Chinese word into your terminal. It will be English.
The Notion client waits out a rate limit instead of failing the sync (#…
WaylandYang commentedon Sep 3, 2026
The fix is on
devas of #269 (f366693): requests are paced at 350 ms and a 429 waits outRetry-Afterinstead of ending the sync. @jeremycapps, when you have a moment:The large workspace is the interesting one. It should now take a few minutes rather than fail; if it passes, that also confirms pagination past 100 pages and 100 blocks, and I'll close this with your result as the record.
jeremycapps commentedon Sep 3, 2026
Ok, I'll have it reran in 2 days. Flagging in case someone wants to step in and rerun it before then.
jeremycapps commentedon Sep 5, 2026
reran it anad all tests passed.
WaylandYang commentedon Sep 5, 2026
That closes it — thank you. Between your two runs this issue got everything it asked for: the small workspace confirmed the connector works against a real one and that
Notion-Version: 2026-03-11is still accepted; the large one found that a 429 was being treated as fatal, and now that it passes, it also confirms pagination past 100 pages and 100 blocks — which nothing on our side could reach without a workspace like yours.#269 is the fix your first run produced. The Chinese line that showed up in your terminal is gone as well: it was the last one left on that path, and it went out in #420.
Closing with your result as the record. Thanks especially for coming back two days later for the rerun — that second run is why this can be closed on evidence rather than left open on a hunch.