Thanks for the PR 🤗 The Sentry node itself looks like a useful addition and the implementation covers many of the expected integration points: node handler, registry, DSL prompt, docs, frontend panel, and tests.

I think there is one important blocker before this can be merged:

The new Sentry credential migration is inserted before an existing migration by changing 090_add_plugins_table.py from 089_workflow_timeout to 090_add_sentry_credential_type. This works on a fresh database, but it can break already migrated databases. Any database that already has 090_add_plugins_table or 091_dashboard_chat_queue applied will not run the new Sentry enum migration, so credential_type will not contain sentry. Creating a Sentry credential would then fail at the DB enum level.

Suggested fix:

• Do not modify the existing 090_add_plugins_table.py migration.
• Add the Sentry enum migration as a new migration after the current head, for example 092_add_sentry_credential_type with down_revision = "091_dashboard_chat_queue".
• Update the Alembic graph tests to verify the new head path instead of asserting that plugins follows Sentry.

A couple of smaller follow-ups I noticed:

• Sentry credential update should probably preserve/merge the existing api_token and base_url, similar to GitHub. Right now editing an existing Sentry credential without re-entering the token, or rotating only one field, can fail or drop the stored base URL.
• Sentry expression fields are defined, but the properties panel does not seem to wire them into the expression dialog navigation like GitHub/Linear/Notion do, so the 1/n field navigation may not work for this node.

Once the migration issue is fixed, this will be much safer to merge. 🎉

Thanks for the PR 🤗 The Sentry node itself looks like a useful addition and the implementation covers many of the expected integration points: node handler, registry, DSL prompt, docs, frontend panel, and tests.

I think there is one important blocker before this can be merged:

The new Sentry credential migration is inserted before an existing migration by changing 090_add_plugins_table.py from 089_workflow_timeout to 090_add_sentry_credential_type. This works on a fresh database, but it can break already migrated databases. Any database that already has 090_add_plugins_table or 091_dashboard_chat_queue applied will not run the new Sentry enum migration, so credential_type will not contain sentry. Creating a Sentry credential would then fail at the DB enum level.

Suggested fix:

• Do not modify the existing 090_add_plugins_table.py migration.
• Add the Sentry enum migration as a new migration after the current head, for example 092_add_sentry_credential_type with down_revision = "091_dashboard_chat_queue".
• Update the Alembic graph tests to verify the new head path instead of asserting that plugins follows Sentry.

A couple of smaller follow-ups I noticed:

• Sentry credential update should probably preserve/merge the existing api_token and base_url, similar to GitHub. Right now editing an existing Sentry credential without re-entering the token, or rotating only one field, can fail or drop the stored base URL.
• Sentry expression fields are defined, but the properties panel does not seem to wire them into the expression dialog navigation like GitHub/Linear/Notion do, so the 1/n field navigation may not work for this node.

Once the migration issue is fixed, this will be much safer to merge. 🎉

Okay, I've updated.

Thank you so much once again 👑 🚀