OpenAPI schema depth truncation rejects valid nested Notion titles

Link to a minimal reproduction

lildesert/eve-openapi-title-repro

The reproduction was initialized with eve@0.53.1 init ., pins the published eve@0.53.1 package, and includes a lockfile. npm's latest tag resolved to 0.53.1 when checked on September 11, 2026.

Steps to reproduce

1. Clone the reproduction repository.
2. Use Node.js 24 and pnpm 11.25.0.
3. Run pnpm install --frozen-lockfile.
4. Run pnpm repro.

title.test.mjs contains two tests with explicit inputs and assertions. It loads a defineOpenAPIConnection through the installed package's internal OpenApiConnectionClient and calls the generated createPage tool's own validator. This tests schema generation and validation directly, without starting an agent session or executing an HTTP request. It requires no credentials or model call.

The valid input is:

{
  "body": {
    "properties": {
      "Name": {
        "title": [{ "text": { "content": "Upload attendee data" } }]
      }
    }
  }
}

Current vs. expected behavior

Current: the generated validator rejects this valid title with Invalid input: more than one option matched. Both alternatives of the nested rich-text oneOf have become {} in the generated schema. As a result, a value matches both alternatives and fails exclusive-union validation. This blocks valid page-creation input before the HTTP request.

Expected: the string title is accepted, while a title with numeric text.content is rejected. Schema conversion should preserve the distinct constraints of deeply nested alternatives.

The numeric input is already rejected in the reproduction; the failing assertion is the valid title.

eve version

eve@0.53.1, installed from npm and pinned in the reproduction lockfile. This was the latest release when the reproduction was rerun on September 11, 2026. I have not identified a last known-good version.

Environment

OS: macOS 26.6.2 (arm64)
Node.js: v24.14.0
Package manager: pnpm 11.25.0
eve info: v0.53.1; nested agent layout; compile ready; 0 errors, 0 warnings

Where does the bug occur?

Other: runtime OpenAPI tool-input schema conversion and validation. The reproduction runs locally without starting a server.

Build and runtime logs

✖ accepts a valid Notion page title
✔ rejects a title with numeric text content
ℹ tests 2
ℹ pass 1
ℹ fail 1

The validation issue has outer path ["body", "properties", "Name"] and this nested error:

{
  "code": "invalid_union",
  "errors": [],
  "inclusive": false,
  "matches": [0, 1],
  "path": ["title", 0],
  "message": "Invalid input: more than one option matched"
}

The first test's assert.equal(result.issues, undefined) fails, and pnpm repro exits with code 1. Node's test runner prints the complete validation error, including the nested union error above. Timings are omitted from the summary here.

Suggested implementation scope

Preserve validation constraints when converting deeply nested OpenAPI schemas, while keeping recursive references finite. Acceptance criteria:

• Accept the valid title in the reproduction.
• Continue rejecting numeric text.content.
• Keep recursive schemas finite and preserve the existing annotation normalization.

I have a local, uncommitted prototype, but no PR has been opened. Would maintainers support a fix at the OpenAPI schema-conversion boundary, and is there a preferred approach?

Additional context

This was encountered when creating a Notion backlog page through an OpenAPI connection. The fixture reduces the property/rich-text union nesting to isolate the failure.

main at dea8cd8 also retains the depth-12 truncation. The emitted [{}, {}] alternatives in the published-package reproduction explain why a structurally valid schema can reject the valid input.

I searched issues, PRs, and discussions for OpenAPI, Notion, schema truncation, MAX_DEREF_DEPTH, derefSchema, rich text, and oneOf. The closest reports describe different behavior:

• OpenAPI connections silently strip request-body properties the spec does not declare (deep objects arrive as {}) #2745 concerns undeclared body properties being stripped. Its triage comment reports no reproduction; this report concerns rejection of explicitly declared nested unions.
• OpenAPI connections pass through default/example values that contradict the schema's own type, causing models to emit invalid tool input #2369 concerns contradictory default/example annotations and was closed by fix(eve): resolve ten session, tool, and integration failures #3082. This reproduction has no such annotations.