Exactly-Once Event Processing Trap
Test di ragionamento per coding agentico su concorrenza, ordering, idempotenza e failure recovery. Il modello deve riconoscere che alcuni requisiti apparentemente implementabili potrebbero essere impossibili da garantire con i vincoli forniti, invece di produrre una soluzione plausibile ma incorretta.
Prompt
Hai un servizio che deve processare eventi provenienti da una coda. Ogni evento ha: event_id user_id timestamp payload Requisiti: gli eventi dello stesso user_id devono essere applicati rigorosamente in ordine di timestamp; utenti diversi possono essere processati in parallelo; il sistema deve essere “exactly once” anche in caso di crash; il database supporta transazioni ACID; la coda garantisce at-least-once delivery ma non garantisce l’ordine; possono arrivare duplicati; un evento con timestamp più vecchio può arrivare dopo uno più recente; il consumer può crashare in qualunque istruzione; non puoi usare lock distribuiti né modificare il comportamento della coda. Un collega propone questa implementazione: def process(event): if db.exists(event.event_id): queue.ack(event) return apply_to_user(event.user_id, event.payload) db.insert_processed(event.event_id) queue.ack(event) Correggi questa implementazione mantenendo il massimo parallelismo possibile. Fornisci: il design corretto; pseudocodice sufficientemente preciso da poter essere implementato; tutte le race condition e failure window rilevanti; una spiegazione rigorosa del perché la soluzione garantisce exactly-once e ordering per utente. Se uno dei requisiti è impossibile da garantire con i vincoli dati, devi dirlo esplicitamente e dimostrarlo invece di inventare una soluzione
