Thanks so much once again 👑 The Notion integration is well put together, and the backend test coverage is strong. The OAuth state handling, credential access checks, and migration merge all look solid.

A few small things before we merge: 🙏

In the OAuth callback, the token exchange catches a broad Exception and returns the raw exception text to the popup. Could you narrow this to the expected error types, such as HTTP and JSON or value errors, and return a generic user-facing message instead? Since this endpoint serves the popup HTML flow, please keep the popup response behavior rather than switching it to an HTTPException response.

Could you also add a typed Pydantic response model for the OAuth authorize endpoint instead of returning a plain dict, to keep it consistent with our API conventions?

There is no Playwright coverage for the new Notion UI flow yet. Please add a practical spec covering at least creation of an internal-token credential and basic Notion node configuration. The OAuth popup itself can be mocked.

Finally, createDataSource currently validates only parent. Please also validate the required properties field locally so users get a clear validation error before making the Notion API request.

Please update the relevant tests alongside these changes. Thanks again, this is close. 🤗

Thanks so much once again 👑 The Notion integration is well put together, and the backend test coverage is strong. The OAuth state handling, credential access checks, and migration merge all look solid.

A few small things before we merge: 🙏

In the OAuth callback, the token exchange catches a broad Exception and returns the raw exception text to the popup. Could you narrow this to the expected error types, such as HTTP and JSON or value errors, and return a generic user-facing message instead? Since this endpoint serves the popup HTML flow, please keep the popup response behavior rather than switching it to an HTTPException response.

Could you also add a typed Pydantic response model for the OAuth authorize endpoint instead of returning a plain dict, to keep it consistent with our API conventions?

There is no Playwright coverage for the new Notion UI flow yet. Please add a practical spec covering at least creation of an internal-token credential and basic Notion node configuration. The OAuth popup itself can be mocked.

Finally, createDataSource currently validates only parent. Please also validate the required properties field locally so users get a clear validation error before making the Notion API request.

Please update the relevant tests alongside these changes. Thanks again, this is close. 🤗

Thanks, I've updated.

Thanks again, the Notion node looks great and the DSL flow works really well. The per-field expression inputs in the properties panel are already there and working, which is great.

One small UX gap to round this out: when users double-click most nodes on the canvas, such as LLM, GitHub, RAG, or Slack, the properties panel opens with the most relevant field already focused and its expression editor ready. Double-clicking a Notion node opens the panel, but no field gets focused, so the expression editor does not open automatically.

Could you wire the Notion node into the same flow?

The main change should be in:

frontend/src/components/Canvas/WorkflowCanvas.vue

Please update handleNodeDoubleClick with a notion branch that selects the field to focus based on notionOperation, similar to the existing GitHub operation mapping. Suggested mapping:

• search to notionQuery
• getPage, updatePage, trashPage, and restorePage to notionPageId
• createPage to notionProperties
• createDatabase to notionDatabase
• retrieveDatabase and updateDatabase to notionDatabaseId
• retrieveDataSource and queryDataSource to notionDataSourceId
• createDataSource to notionDataSource
• updateDataSource to notionDataSourceId
• getBlockChildren, updateBlock, deleteBlock, and appendBlocks to notionBlockId

For the focus to land correctly, please also update:

frontend/src/components/Panels/PropertiesPanel.vue

The Notion ExpressionInput fields need template refs, and the existing focusField handler needs matching Notion cases so the selected field receives focus and opens its expression editor.

The goal is for double-clicking a Notion node to immediately focus the right parameter for the selected operation and open the expression editor, exactly like the other nodes already do. Please add or update tests where practical.