Runbook: rollback API

Quando usarlo

Usare questo runbook quando il deployment API introduce una regressione isolata e il target precedente è noto e compatibile con lo schema D1 corrente.

Prerequisiti

• trigger di rollback provato;
• autorizzazione di rollback esplicita o pre-autorizzata nell'Issue;
• versione API precedente registrata;
• compatibilità con D1 verificata;
• Frontend e route ownership non inclusi nella mutazione;
• baseline da ripristinare definita.

Procedura

1. Fermare ogni altra mutazione.
2. Confermare che il problema appartenga all'API, non a D1 o Frontend.
3. Registrare la versione attuale e il target.
4. Ripristinare il target:

npx wrangler rollback <VERSIONE_API_PRECEDENTE> \
  --env <AMBIENTE> \
  --yes

1. Attendere il risultato terminale.
2. Verificare /health, /version e /db/health.
3. Verificare Access, CORS esatto e route API.
4. Eseguire npm run smoke:cutover:rollback nel contesto autorizzato.

Verifiche attese

• una sola versione API ripristinata;
• API health e D1 health verdi;
• Frontend e dominio pubblico invariati;
• Access e CORS ancora chiusi all'origine esatta;
• nessuna migrazione o mutazione editoriale.

Condizioni di stop

Fermarsi se il target non è univoco, D1 non è compatibile, la causa coinvolge più componenti, il rollback è ambiguo o la baseline non torna verde.

Rollback o recupero

Non eseguire un secondo rollback nella stessa autorizzazione. Mantenere lo stato fail-closed e aprire un Issue di recupero con l'evidenza disponibile.

Evidenza da conservare

• trigger;
• versione API fallita e target;
• autorizzazione;
• risultato Wrangler;
• health, D1, Access, CORS e route;
• conferma che Frontend e D1 non sono stati mutati;
• rischio residuo.