GeezerVison

Summary

Follow-up to #6593. fetchTableSchema is the last enricher still calling the deprecated buildAuthHeaders, and after #6593 migrated its two siblings in the same file it now reads like a missed migration. It isn't — and "fixing" it today would break table tools.

• GET /api/table/[tableId] authenticates through checkSessionOrInternalAuth → verifyInternalToken, which requires type: 'internal'. An executor delegation carries type: 'internal_delegation' and is rejected, then falls through to session auth the executor doesn't have.
• The sibling table routes ([tableId]/groups, [tableId]/exports, imports/*) are already on internalTableSessionOrExecutorAuth, so this route is the straggler and a plausible next migration target.
• tables.read also declares delegatedServices: ['copilot'], so an executor delegation would be refused at the operation layer even if the route accepted it.

So: assert the route still authenticates through the legacy path, and record on the caller why it is deliberately not migrated. The migration that flips this route now fails on a test that names the caller, instead of shipping and breaking table tools.

Why not migrate the route here

readTableUseCase exists, but this GET returns an 18-field payload including maxRows from getWorkspaceTableLimits, which the use case does not supply, and the response is consumed by the Tables UI. Doing it properly means a new contract matched field-by-field against the current output plus widening tables.read's principal policy — a scoped migration of its own, not a follow-up rider on something that isn't broken.

Correction to how this was previously described

I earlier called this a latent copy of the #6593 bug. The auth coupling is the same; the failure mode is the opposite. enrichTableToolSchema is wired as a tool-level toolEnrichment, and createLLMToolSchema wraps those in ToolSchemaEnrichmentError naming the tool — so a break here fails the Agent block loudly rather than silently degrading the schema the way the workflow and knowledge enrichers did. That is why this is a guard rather than a fix.

Type of Change

• Test / maintainability

Testing

• Verified the guard actually trips: stubbed out the route's checkSessionOrInternalAuth call and the new test failed while the existing PATCH tests stayed green, so it is targeted rather than incidental.
• bunx vitest run app/api/table/ tools/ — 2,746 passing.
• Repo-wide lint:check, type-check, and check:api-validation.
• No runtime behavior change.

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)