fix(uploads): sign transfers for in-process v2 callers that carry no network origin

Merged
WA
20d ago
+300-5

Summary

  • requestOrigin() threw "Upload signing requires a request origin" for in-process v2 callers. Chat's CLI (scoped in-process transport) and MCP tool dispatch build NextRequests with no Origin/Host headers. The nextUrl instanceof URL branch never matched, because NextRequest.nextUrl is a NextURL, not a URL.
  • Because of that, knowledge document upload create/parts, table import create/parts, and workspace file upload parts failed for those callers on every storage provider. The origin is only read by the local provider.
  • A network request still resolves its origin from the Origin header first, then x-forwarded-host/host, so browser and proxied self-hosted behavior is unchanged. A request with neither now uses the URL it was addressed to: the CLI's configured endpoint, or the app URL for MCP. A context without a URL falls back to the configured app URL instead of throwing.
  • Removed the dead nextUrl branch. Added an optional url to OrchestrationRequestContext, which NextRequest already satisfies.

Type of Change

  • Bug fix

Testing

  • New requestOrigin unit tests. The in-process case reproduced the thrown error before the fix and passes after it.
  • New integration test that drives knowledge upload, table import, and workspace file create + parts through createScopedCliTransport and dispatchMcpOperation on local storage, with no host headers. It asserts the PUT and part URLs point at the CLI endpoint and at the app URL respectively. The existing use-case tests mocked requestOrigin, so none of them exercised a header-less request.

Checklist

  • Code follows project style guidelines
  • Self-reviewed my changes
  • Tests added/updated and passing
  • No new warnings introduced
  • I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)