Conversation
🐳 Docker Image PublishedYour Docker image has been built and pushed for this PR. Image Reference: Platforms: linux/amd64, linux/arm64 TestingTo test this image: docker pull docker.io/communityfirst/comapeo-docs-api:pr-156
docker run -p 3001:3001 docker.io/communityfirst/comapeo-docs-api:pr-156Built with commit f94f25a |
🚀 Preview DeploymentYour documentation preview is ready! Preview URL: https://pr-156.comapeo-docs.pages.dev 🔄 Content: Regenerated 5 pages from Notion (script changes detected)
This preview will update automatically when you push new commits to this PR. Built with commit f94f25a |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f94f25aa47
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (pageId) { | ||
| const rawPage = await notion.pages.retrieve({ page_id: pageId }); | ||
| const page = transformPage(rawPage as any); | ||
|
|
||
| return { | ||
| pages: [page], | ||
| rawPages: [rawPage as Record<string, unknown>], | ||
| candidateIds: [], | ||
| fetchedCount: 1, | ||
| processedCount: 1, | ||
| }; | ||
| } |
There was a problem hiding this comment.
Route page-id fetches through content generation
The new pageId fast-path returns before runFetchPipeline runs, so generateBlocks is never executed for --page-id requests. In the new fetch-one flow this function is called with export enabled, so jobs can report pagesProcessed: 1 while producing no generated docs/images to stage and commit, which makes successful fetch-one runs a no-op for content sync.
Useful? React with 👍 / 👎.
| jobType === "fetch-ready" || | ||
| jobType === "fetch-all" || | ||
| jobType === "notion:fetch" || | ||
| jobType === "notion:fetch-all" || | ||
| jobType === "notion:translate" | ||
| ); |
There was a problem hiding this comment.
Keep legacy fetch jobs marked as content mutating
Removing notion:fetch and notion:fetch-all from isContentMutatingJob regresses existing API job types that are still valid in JOB_COMMANDS/validation. Those jobs will now bypass content-repo orchestration (no runContentTask commit/push workflow and weaker preflight checks), so clients using legacy fetch types can get successful runs without the expected managed content-branch sync behavior.
Useful? React with 👍 / 👎.
Summary
Testing