feat(neon-auth): make Neon Auth prerequisite explicit and approval-gated in get/configure#262
Open
Shridhad wants to merge 1 commit into
Open
feat(neon-auth): make Neon Auth prerequisite explicit and approval-gated in get/configure#262Shridhad wants to merge 1 commit into
Shridhad wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Both `get_neon_auth_config` and `configure_neon_auth` operate on a Neon Auth integration that must already exist on the target branch. When that prerequisite isn't met, today's responses leave the LLM with two bad options: chain into `provision_neon_auth` automatically (provisioning has side effects — schema, service deploy, possible cost) or surface a generic 404 the user can't act on. Tighten both layers: - Tool descriptions: add a PREREQUISITES block to both tools that spells out the side effects of provisioning and tells the LLM to surface the prerequisite to the user and obtain explicit approval before calling `provision_neon_auth`. - Handlers: add a single shared `NEON_AUTH_NOT_PROVISIONED_MESSAGE` and use it on the 404 path of `handleGetNeonAuthConfig`. Pre-flight `configure_neon_auth` with `ensureNeonAuthProvisioned` (one extra GET on `getNeonAuth`) so the handler returns the same actionable message before invoking any per-op SDK call. The probe also disambiguates "Neon Auth not provisioned" from op-meaningful 404s such as an unknown OAuth provider id on `update_oauth_provider`. Tests: - Existing `get_neon_auth_config` 404 test tightened to assert the approval-gate wording. - New `handleConfigureNeonAuth prerequisite probe` block: short-circuit on a PR1 op (`add_trusted_origin`) and a PR2 op (`add_oauth_provider`) with both wording and "mutation SDK not called" assertions, plus a non-404 upstream failure that returns a generic verify-failed message so it can't be conflated with the provisioning prerequisite. - `defaultSnapshotMocks()` gains a default `getNeonAuth: 200` so existing tests stay green; three tests that intentionally hand-roll narrow `neonClient` mocks now satisfy the prereq probe explicitly.
Shridhad
force-pushed
the
feat/neon-auth-prereq-hints
branch
from
d944d71 to
231b9eb
Compare
thekauer
added a commit
that referenced
this pull request
May 20, 2026
…ating tools Ports the prerequisite-probe pattern from `#262` (by @Shridhad) onto the restructured 8-tool surface. Without it, calling any mutating Neon Auth tool against a branch where Neon Auth is not provisioned yields an opaque per-op 404 — and on tools like `neon_auth_oauth_provider_update` or `neon_auth_oauth_provider_delete` the per-op 404 is genuinely ambiguous (unknown provider id vs auth not provisioned). Pattern, mirrors PR #262: - `ensureNeonAuthProvisioned()` helper in `neon-auth-utils.ts` issues a single `getNeonAuth()` probe up front. 200 → return null and let the handler proceed; 404 → short-circuit with the canonical `NEON_AUTH_NOT_PROVISIONED_MESSAGE` (worded to gate the LLM's next action: surface the prerequisite to the user, explain side effects, ask for explicit approval before calling `neon_auth_provision`); other status → generic "Failed to verify Neon Auth provisioning" so a 5xx outage cannot be misrepresented as "not provisioned". - All seven non-provision handlers (methods_update, oauth_provider_*, domain_update, webhook_update, send_test_email) call the helper after branch resolution and before any per-op SDK call. - All seven tool descriptions in `definitions.ts` gain a PREREQUISITES block matching the wording used by PR #262. - Tests: integration suite gains a "Neon Auth preflight" describe block — 404 short-circuits each major handler family without invoking the per-op SDK, and 5xx returns the verify-failed message (NOT the approval-gate message). Cost: one extra GET per non-provision tool call. Worth it to avoid ambiguous 404s and silent auto-provisioning. Co-authored-by: Isaac
thekauer
added a commit
that referenced
this pull request
May 22, 2026
…ating tools Ports the prerequisite-probe pattern from `#262` (by @Shridhad) onto the restructured 8-tool surface. Without it, calling any mutating Neon Auth tool against a branch where Neon Auth is not provisioned yields an opaque per-op 404 — and on tools like `neon_auth_oauth_provider_update` or `neon_auth_oauth_provider_delete` the per-op 404 is genuinely ambiguous (unknown provider id vs auth not provisioned). Pattern, mirrors PR #262: - `ensureNeonAuthProvisioned()` helper in `neon-auth-utils.ts` issues a single `getNeonAuth()` probe up front. 200 → return null and let the handler proceed; 404 → short-circuit with the canonical `NEON_AUTH_NOT_PROVISIONED_MESSAGE` (worded to gate the LLM's next action: surface the prerequisite to the user, explain side effects, ask for explicit approval before calling `neon_auth_provision`); other status → generic "Failed to verify Neon Auth provisioning" so a 5xx outage cannot be misrepresented as "not provisioned". - All seven non-provision handlers (methods_update, oauth_provider_*, domain_update, webhook_update, send_test_email) call the helper after branch resolution and before any per-op SDK call. - All seven tool descriptions in `definitions.ts` gain a PREREQUISITES block matching the wording used by PR #262. - Tests: integration suite gains a "Neon Auth preflight" describe block — 404 short-circuits each major handler family without invoking the per-op SDK, and 5xx returns the verify-failed message (NOT the approval-gate message). Cost: one extra GET per non-provision tool call. Worth it to avoid ambiguous 404s and silent auto-provisioning. Co-authored-by: Isaac
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Both
get_neon_auth_configandconfigure_neon_authrequire Neon Auth to already be provisioned for the target branch. Today, when that prerequisite isn't met, the response leaves the LLM with two bad options:provision_neon_authautomatically — but provisioning has side effects (creates theneon_authschema, deploys an auth service, may incur cost), so silent auto-provisioning is the wrong UX.Failed to add trusted origin (404 Not Found). Ensure Neon Auth is provisioned…) — but that's ambiguous; onupdate_oauth_providera 404 could equally well mean "unknown OAuth provider id".This PR tightens both layers so the LLM gets a single, actionable message and an explicit approval gate.
What changed
Tool descriptions (
landing/mcp-src/tools/definitions.ts)Added a
PREREQUISITES:block to bothget_neon_auth_configandconfigure_neon_auth, in the same prose style as the existingSECURITY:block. Spells out (a) the side effects of provisioning and (b) the requirement to surface the prerequisite to the user and obtain explicit approval before callingprovision_neon_auth.Shared "not provisioned" message (
landing/mcp-src/tools/handlers/neon-auth-config.ts)Added a single canonical
NEON_AUTH_NOT_PROVISIONED_MESSAGEconstant exported fromneon-auth-config.tsso both handlers render exactly the same wording. Wording is deliberately prescriptive about the approval gate.Pre-flight probe in
configure_neon_authAdded an internal
ensureNeonAuthProvisioned()helper that callsgetNeonAuthonce at the top ofhandleConfigureNeonAuth. On 404 it returns the canonical message and short-circuits before any per-op SDK call; on 200 it proceeds; on other statuses it returns a generic "Failed to verify Neon Auth provisioning" error so a 5xx outage can't be misrepresented as "not provisioned".This costs one extra GET per
configure_neon_authcall but:update_oauth_provider); andget_neon_auth_config404 pathRefactored to use the shared constant instead of its previous local string; no extra round-trip (it already calls
getNeonAuth).Tests
get_neon_auth_config404 test to assert the approval-gate wording (ask the user,explicit approval,side effects,provision_neon_auth).handleConfigureNeonAuth prerequisite probedescribe block:add_trusted_origin(PR1 op) ongetNeonAuth: 404and verifies the per-op SDK mutation was NOT called.add_oauth_provider(PR2 op).getNeonAuth: 500, returns a generic verify-failed message that does NOT contain approval-gate keywords (defends against misrepresenting an outage as "not provisioned").defaultSnapshotMocks()gains a defaultgetNeonAuth: 200mock so existing tests stay green.neonClientmocks (theupdate_auth_methodsschema/handler-skew test, and twosend_test_emailtests that assert no snapshot reload) now satisfy the prereq probe with a one-linegetNeonAuth: 200addition.Test plan
pnpm run typecheckclean.pnpm run lintclean.pnpm run fmt:checkclean.pnpm run knipclean.pnpm run test:unit— 338 passed (was 335; +3 new prereq tests).pnpm run test:integration— 85 passed.Notes
configure_neon_authoperations uniformly via the single pre-flight probe.