skald-connectors/docs/bug-report-verify-docker-exec.md

Bug report: verify dei connector MCP in container fallisce con exec: "-e": executable file not found

Progetto: skald-circle (non il marketplace) File: crates/skald-core/src/mcp/verify.rs Introdotto da: commit e6c4e20 — "feat(mcp): OAuth per-user connectors (§15) — providers, PKCE copy-paste flow, env credential delivery" Priorità: alta — blocca l'attivazione di tutti i connector mcp_local + scope: user che hanno env/secret nel verify (LinkedIn ora, Email alla prossima riattivazione)

---

1. Sintomo

Attivando il connector linkedin (mcp_local, scope user) dal frontend, il verify fallisce con:

Failed — OCI runtime exec failed: exec failed: unable to start container process: exec: "-e": executable file not found in $PATH

2. Causa radice

In crates/skald-core/src/mcp/verify.rs (~righe 144-152) il comando docker exec viene costruito con il nome del container PRIMA delle opzioni -e:

VerifyTarget::Container { container, workdir } => {
    let mut c = tokio::process::Command::new("docker");
    c.arg("exec")
        .arg("-w").arg(workdir)
        .arg(container);                               // ← container name
    inject_env_flags(&mut c, env_values, secret_values); // ← -e KEY=VAL DOPO il container
    c.arg("sh").arg("-c").arg(&resolved);
    c
}

inject_env_flags (righe 285-293) aggiunge cmd.arg("-e").arg(format!("{k}={v}")) per ogni env/secret.

Risultato: viene generato

docker exec -w <workdir> <container> -e KEY=VAL -e KEY2=VAL2 sh -c "python3 verify.py"

La sintassi di docker exec è docker exec [OPTIONS] CONTAINER COMMAND [ARG...]: dopo il nome del container ogni argomento è interpretato come COMMAND. Docker prova quindi a eseguire l'eseguibile -e → errore OCI.

3. Connector colpiti

Il bug scatta solo quando env_values/secret_values non sono vuoti, cioè quando il manifest del connector dichiara env[] (o secret) e il verify gira in container:

Connector	Container?	Verify con env?	Colpito
linkedin	✅ user	✅ 2 secret + 3 env	❌ si — errore visibile
email	✅ user	✅ 8 env	❌ si — già attivo, fallirà alla prossima riattivazione
gcal / drive / gmail	✅ user	credenziali OAuth via altro path	probabilmente no
gmaps, context7, tavily…	host / global	VerifyTarget::Host	no

Nota: il path di lancio del server MCP in crates/mcp-client/src/server.rs (~righe 261-273) costruisce lo stesso comando nell'ordine corretto (-i, poi -e …, poi container) — usarlo come riferimento.

4. Fix suggerito

Spostare inject_env_flags prima di .arg(container) in verify.rs:

VerifyTarget::Container { container, workdir } => {
    let mut c = tokio::process::Command::new("docker");
    c.arg("exec").arg("-w").arg(workdir);
    inject_env_flags(&mut c, env_values, secret_values); // ← spostato qui
    c.arg(container);
    c.arg("sh").arg("-c").arg(&resolved);
    c
}

Il comando generato diventa:

docker exec -w <workdir> -e KEY=VAL -e KEY2=VAL2 <container> sh -c "python3 verify.py"

5. Verifica consigliata

1. Test unitario: aggiungere un test che costruisca il comando per VerifyTarget::Container e verifichi l'ordine degli argomenti (docker exec -w <wd> -e K=V <container> sh -c …). I test esistenti in verify.rs coprono solo apply_placeholders.
2. E2E: riattivare linkedin dal frontend (deve superare il verify con il cookie li_at).
3. Regressione: riattivare email (8 env) per confermare che il bug era latente anche lì.