0022. Workspace registry: i connettori Noeva possono puntare solo a workspace configurati

• Stato: Accettata
• Data: 2026-07-16
• Decisori: Team BI/ETL

Contesto

Con il multi-workspace (ADR-0021) una singola istanza ETL conosce N workspace via NOEVA_WORKSPACE_IDS. Introducendo pipeline cross-workspace (es. cross-workspace-csv-merge, che legge/scrive su due workspace), serve una risposta a: quali workspace una pipeline può toccare.

Un connettore Noeva (noevaFileSource/noevaFileSink) è legato a un singolo workspace via NoevaClientConfig (baseUrl + apiKey condivisa + workspaceId). L'API key è una sola per tutti i workspace, quindi la selezione del workspace è solo l'id nell'header x-noeva-workspace: senza una guardia, una pipeline potrebbe puntare a un workspace qualsiasi, anche non previsto per quell'istanza — un rischio operativo e di isolamento tra tenant.

Decisione

I workspace configurati (NOEVA_WORKSPACE_IDS, o il singolo NOEVA_WORKSPACE_ID) sono l'unica fonte di verità dei workspace che l'istanza può toccare. Un connettore Noeva può puntare solo a un workspace presente in quella configurazione; risolverne uno non configurato è un errore fail-fast.

• Nuovo WorkspaceRegistry (src/connectors/noeva/workspace-registry.ts): buildWorkspaceRegistry(configs: NoevaClientConfig[]) costruisce una mappa workspaceId → config. config(id)/client(id) lanciano ConfigError se il workspace non è configurato; il messaggio elenca gli id ammessi, mai le API key.
• Dependency-injected: il registry riceve le config già risolte e non importa worker/config — la composizione (run.ts della pipeline) legge i workspace configurati via loadEtlWorkerConfigs(env).map(c => c.apiClientConfig) e costruisce il registry. Le credenziali di ogni workspace vengono quindi sempre dal registro configurato, non da prefissi env ad-hoc per-pipeline.
• Le pipeline cross-workspace risolvono i client tramite il registry: puntare a un workspace non ammesso fallisce prima di qualsiasi I/O.

Alternative considerate

• Prefissi env dedicati per la seconda pipeline (es. NOEVA_B_*) — scartata: ogni pipeline reinventerebbe la propria risoluzione credenziali, senza una guardia comune su "quali workspace sono ammessi". Il registry centralizza fonte e validazione.
• Nessuna validazione (fidarsi dell'id passato) — scartata: consentirebbe di operare su workspace non previsti per l'istanza, contro l'isolamento tra tenant.

Conseguenze

• Le pipeline cross-workspace richiedono che tutti i workspace target siano elencati in NOEVA_WORKSPACE_IDS (o, per il singolo workspace, in NOEVA_WORKSPACE_ID). In caso contrario la run fallisce subito con un errore chiaro.
• La validazione è riusabile: qualsiasi futura pipeline che tocca workspace multipli usa lo stesso registry. L'adozione nei connettori esistenti è incrementale (non è un refactor obbligato di tutto il codice attuale).
• Nessun segreto nei messaggi d'errore: si stampano solo gli id dei workspace ammessi.