Produits Entr'ouvert » w.c.s.

Dans wcs/sql.py sur le role.store, quand le rôle a déjà un id on fait ceci :

   3076             sql_statement = '''UPDATE %s SET %s WHERE id = %%(id)s RETURNING id''' % (
   3077                 self._table_name,
   3078                 ', '.join(['%s = %%(%s)s' % (x, x) for x in column_names]),
   3079             )
   3080             cur.execute(sql_statement, sql_dict)
   3081             if cur.fetchone() is None:
   3082                 sql_statement = '''INSERT INTO %s (%s) VALUES (%s)''' % (
   3083                     self._table_name,
   3084                     ', '.join(column_names),
   3085                     ', '.join(['%%(%s)s' % x for x in column_names]),
   3086                 )
   3087                 cur.execute(sql_statement, sql_dict)

Mais on vient de voir un crash sur la dernière ligne :

oct. 30 10:29:16 publik-test uwsgi[2592664]:   File "/usr/lib/python3/dist-packages/wcs/sql.py", line 3087, in store
oct. 30 10:29:16 publik-test uwsgi[2592664]:     cur.execute(sql_statement, sql_dict)
oct. 30 10:29:16 publik-test uwsgi[2592664]: psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "roles_pkey" 
oct. 30 10:29:16 publik-test uwsgi[2592664]: DETAIL:  Key (id)=(a43b22d323d74f0ca2783f14d9ec4792) already exists.

Il me semble que, bien qu'on soit dans une transaction, ce cas soit effectivement possible, ie que le rôle ait été créé entre temps (par un provisioning en cours), et paf conflit sur id qui est la clé primaire.

Je crois qu'on devrait avoir un try/except sur ce dernier cur.execute et faire juste un rollback en cas de psycopg2.errors.UniqueViolation (ou psycopg2.IntegrityError ?)