fix(sparql): fallback GET anche su timeout/rete + errore GET 5xx

[Gabrymi93]

Sintesi

Completa il fix SPARQL del POST 403 (#447) con i casi che il docstring prometteva ma il codice non copriva: timeout/errore di rete e GET fallback con 5xx.

Contesto collegato

• Estende il fix fix(sparql): POST 403 → fallback GET (WAF/Virtuoso, caso Senato) #447 (merged, v1.47.3)
• Rilevato lavorando su senato-ddl (dataset-incubator #781): il POST al Senato può fallire con errore di rete (non solo 403), e in quel caso il GET fallback non scattava

Cosa cambia

• Bug fix
• Nuova funzionalità del motore
• Nuovo plugin sorgente
• Modifica contratto pubblico
• Refactor / performance
• Documentazione
• Dipendenze o CI

Impatto su contratti pubblici

Nessuno — comportamento interno del fetch.

Dettaglio

Prima (gap del #447):

• POST con errore di rete/timeout (post_status is None) → raise DownloadError("POST → unknown") senza provare il GET — nonostante il docstring dicesse "Se POST fallisce (403, timeout), prova GET"
• GET fallback che restituisce 5xx → messaggio generico senza lo status

Dopo:

• fallback GET scatta anche quando il POST fallisce con errore di rete/timeout (post_status is None)
• GET fallback 5xx → DownloadError("SPARQL GET fallback returned HTTP {status}") esplicito
• POST 5xx → errore esplicito (già dal fix(sparql): POST 403 → fallback GET (WAF/Virtuoso, caso Senato) #447, invariato)

Verifica

pytest tests/test_sparql_plugin.py  # 26 passed (4 casi: 403→GET, timeout→GET, GET 5xx→err, POST 5xx→err)
mypy toolkit/plugins/sparql.py      # no issues
ruff check .                        # ok

Verifica end-to-end sul Senato reale: SparqlSource.fetch(dati.senato.it, ...) → POST fallisce → GET fallback → dati CSV restituiti.

Note

• Il test test_sparql_fetch_post_timeout_falls_back_to_get copre il caso timeout
• Il test test_sparql_fetch_get_fallback_5xx_raises copre il GET fallback con 500
• I test esistenti (fix(sparql): POST 403 → fallback GET (WAF/Virtuoso, caso Senato) #447) continuano a passare invariati