`importObject`'s `opts.name` override bypasses the namespace prefix and persists an unprefixed federated object

[os-warren]

Found while working #10712 (PR #11059), which gave generateObjectDraft a
${namespace}_ prefix derived from the datasource's owning package. Filed rather than
fixed there: #10712 is scoped to the draft output, and this is a different path with
a different question behind it. Unassigned, awaiting first-touch grading.

What

ExternalDatasourceService.importObject reuses the draft pipeline, so it inherits the
prefix — but only when the caller does not name the object itself:

const name = opts.name ?? draft.name;

opts.name is taken verbatim. A caller passing { "name": "customers" } gets an object
persisted as customers, with no ${namespace}_ prefix, via
persistObject → metadata.register('object', name, definition).

Reachable today

Not hypothetical, and not dependent on #10712's change. ImportObjectOpts extends GenerateDraftOpts with name?: string ("Override the auto-derived object name"), and
the import route forwards the request body as opts unfiltered —
packages/rest/src/external-datasource-routes.ts:462:

const result = await svc.importObject(
 req.params.name,
 /* remote */ …,
 (req.body as Record<string, unknown>) ?? {},
);

So POST /api/v1/datasources/:name/external/tables/:remote/import with
{"name": "customers"} reaches it.

Why this is not simply "the caller owns the name"

That reading is defensible on its own, and may well be the right ruling — but the
runtime write path this lands on does not apply the check that would catch it.
validateObjectNamespacePrefix runs in two places: defineStack() (compile time) and
MetadataManager.publishPackage / the protocol's publish pre-flight (the Studio
"publish" path, NAMESPACE_PREFIX). metadata.register('object', …) is neither. So an
imported object with an explicitly unprefixed name is registered and served without any
gate having looked at the name.

Note the in-tree callers do not currently exercise this: objectui's
ImportObjectDialog posts no name, and os datasource introspect does not import at
all. The exposure is the route body.

The question a first-touch should answer

Three shapes, none of which a dev should pick unilaterally:

• A. Apply the prefix to opts.name too (same validateObjectNamespacePrefix
  treatment as the derived name). Consistent, but silently rewrites a name the caller
  explicitly asked for.
• B. Refuse an opts.name that fails the prefix rule, with the rule's own actionable
  message. Contract-first, and matches what the publish gate does with the same
  violation — but it turns a currently-accepted request into a 4xx.
• C. Leave it: an explicit override is the caller's decision. Then the gap worth
  closing is arguably the broader one — that metadata.register('object', …) applies no
  namespace check at all — which is a much wider question than this seam.

Related: #10712 / PR #11059 (the draft half, where the prefix derivation lives),
#11000 (the unauthorable primaryKey key in the same generator).

[os-zhuang]

Triage: pm:queue, domain:services, Bug. importObject's opts.name override bypasses the namespace prefix and persists an unprefixed federated object — invariant restore (the prefix rule is the declared behavior); loud refusal or forced prefixing, implementer argues which in the PR.

---

Generated by Claude Code

[os-sam]

Claim: PM loop round 2
Session: session_01APWX2AwT3a4xDcjPCe8bk4
Branch: claude/issue-11061-import-object-namespace-prefix
Worktree: objectstack-issue-11061
Domain: domain:services
File surface: packages/services/service-datasource/src/external-datasource-service.ts (the importObject name seam) + its tests + changeset; ⚠️ packages/rest/src/external-datasource-routes.ts only if the chosen shape requires it — report before touching it (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: fable — ⛔ Clause-② mandate, not a judgment call. Tier re-read live this round at scripts/pm/dispatch-gates.mjs:2732 (CONTRACT_REVIEW_TIER = 'claude-fable-5').
Clause-②: yes
Serial constraints cleared: service-datasource was released when PR #11206 merged (9883f58c4d) — no holder. #11184/PR #11211 holds plugin-security + plugin-auth; #10692 (dispatched this round) holds plugin-sharing. No overlap. ⚠️ #10962 (validateObject re-introspects the datasource) is queued and lands in the same package — ⛔ it is deliberately not dispatched this round; this claim holds external-datasource-service.ts until its PR merges.

Clause-② determination

yes, judged from card content, not paths. Of the three shapes the card names, triage has already removed C from the table (below), and both survivors change runtime accept/reject behaviour on a request the API accepts today:

• B turns a currently-accepted POST …/import body into a 4xx.
• A silently rewrites a name the caller explicitly supplied, changing what gets persisted for an unchanged input.

⚠️ Note the mechanical adjudication test ("restoring declared = enforced is a bug, not a feature") is a different test for a different purpose — it decides who may adjudicate, not the review tier. Clause-② asks whether contract accept/reject behaviour moves. It does. So: draft PR, needs:contract-review on this card from claim time, ⛔ this seat does not clear it (it runs below tier), no ready-flip, no auto-merge.

Ruling carried from triage — comment 5383472206, binding

invariant restore (the prefix rule is the declared behavior); loud refusal or forced prefixing, implementer argues which in the PR.

Two consequences, both load-bearing:

• ⛔ Option C is off the table. "The caller owns the name" is not available: triage ruled the prefix rule is declared behaviour, so this is an invariant restore.
• A vs B is the implementer's call, with the argument in the PR. ⛔ Do not treat that as licence to pick the cheaper one silently — the argument is the deliverable, and it must engage the cost each shape carries (A rewrites a caller's explicit input; B breaks a request that works today).

Premise check at claim time

Card is ~14 h old with a triage comment 3 h old; the action face is fresh. The reachability claim is the part that matters and it is precise enough to verify from the tree rather than assume: ImportObjectOpts extends GenerateDraftOpts with name?: string, and the route forwards req.body as opts unfiltered at packages/rest/src/external-datasource-routes.ts:462. ⚠️ Re-verify that line number yourself — packages/rest has taken commits since the card was filed.

The card's own scoping note is worth keeping: in-tree callers do not exercise this (objectui's ImportObjectDialog posts no name; os datasource introspect does not import). The exposure is the route body, which is exactly why "no in-tree caller does this" is not a defence.

---

Generated by Claude Code