Three datasource-admin routes answer 503 naming the wrong service (carried out of #3973 so it is not buried)

[os-zhuang]

Recorded as an "adjacent, one line" note at the bottom of #3973. That issue is closed by the builder consolidation, which does not touch this — so filing it separately rather than letting it go down with the issue that mentioned it.

The finding

packages/services/service-datasource/src/admin-routes.ts has one shared 503 helper:

const unavailable = (res: any) =>
  sendError(res, 503, 'SERVICE_UNAVAILABLE', 'The datasource-admin service is not available.');

Nine routes call it. Six of them resolve adminService(), so the message is right. Three resolve externalService() — a different service — and still answer that the datasource-admin service is unavailable:

Route	resolves	503 message says
GET /:name/remote-tables	externalService()	datasource-admin
POST /:name/test	externalService()	datasource-admin
POST /:name/object-draft	externalService()	datasource-admin

So an operator whose external-datasource service is unwired is told to go look at datasource-admin, which is running fine.

Why the code is not the bug

SERVICE_UNAVAILABLE is correct for all nine — ADR-0112's ledger explicitly asks generic conditions to reuse the standard catalog rather than register a per-service 503 synonym, and admin-routes.ts documents that decision inline. Which service is down is carried by message, exactly as intended. The message is simply wrong on three routes.

Fix

Give unavailable a service-name parameter (or add a second helper), so the three external-datasource routes name external-datasource. packages/rest/src/external-datasource-routes.ts already has the correct string for its own surface:

sendError(res, 503, 'SERVICE_UNAVAILABLE', 'The external-datasource service is not available.');

Pre-existing — #3843 deliberately carried every code string over verbatim, and #3973 changed no bytes on the wire. A natural pickup for whoever next sweeps this module.