En moltes aplicacions Django es tendeix a utilitzar sleep dins d'una tasca d'Api per evitar condicions de carrera quan la tasca intenta llegir dades que acaben de crear-se a la base de dades. Per exemple, reconstruir etiquetes després de crear un usuari i afegir sleep per esperar que la transacció es completi no és una solució fiable ni recomanable.
L'ús de sleep és fràgil perquè depèn de temps arbitraris, alenteix el sistema i amaga el veritable origen del problema. Si la tasca rebuild_tags rep només student_id i espera un segon amb sleep per després consultar el model User pot funcionar de vegades i fallar altres, sobretot sota càrrega o amb latències variables entre serveis.
La forma correcta és assegurar que la tasca es llança només quan la transacció que crea les dades ha estat confirmada. Django proporciona transaction.on_commit per executar un callable just després del commit de la transacció. A la pràctica s'usa transaction.on_commit amb una crida que llança la tasca d'Api, per exemple passant una funció que invoqui rebuild_tags.delay amb els arguments necessaris. D'aquesta manera s'evita sleep i es garanteix que la tasca veu les dades persistides.
Un altre detall important és com es defineixen els paràmetres de la tasca perquè eines com Flower mostrin arguments clars. Si volem que els paràmetres anomenats apareguin a kwargs convé forçar paràmetres només per nom utilitzant sintaxi que accepti args extres i després paràmetres keyword only, per exemple acceptar qualsevol cosa amb asterisc i declarar student_id com a argument per nom. Així a Flower la tasca es veurà com args buits i kwargs amb student_id igual a un valor, la qual cosa millora la llegibilitat i el diagnòstic.
En escenaris amb celery beat i tasques programades és habitual enviar arguments serialitzables en format json. Per evitar confusions és recomanable declarar paràmetres per nom amb valors per defecte i passar a la programació alguna cosa similar a {hour:17, minute:47} per indicar l'hora i el minut desitjats. D'aquesta manera la tasca rep paràmetres explícits i el comportament és previsible.
Nota sobre proves TDD: si durant els tests apareix sleep és senyal que la prova o el codi no estan aïllant la transacció correctament. En proves unitàries convé utilitzar transaction.on_commit o simular el comportament de llançament de tasques per evitar sleeps i fer tests deterministes i ràpids.
En Q2BSTUDIO, empresa especialista en desenvolupament de programari a mida i aplicacions a mida, apliquem aquestes bones pràctiques en arquitectures amb Api per garantir fiabilitat i escalabilitat. Oferim serveis integrals que inclouen programari a mida, intel·ligència artificial i ia per a empreses, agents IA, ciberseguretat, serveis cloud aws i azure i serveis intel·ligència de negoci. També implementem solucions analítiques amb power bi i acompanyem els equips en l'adopció de pràctiques de desplegament segur i proves automatitzades.
Si busques optimitzar processos asíncrons, evitar race conditions i millorar l'observabilitat de les tasques amb Api, contacta amb Q2BSTUDIO per dissenyar i implementar solucions robustes, segures i escalables en programari a mida, intel·ligència artificial, ciberseguretat i serveis cloud aws i azure.
