Projet

Général

Profil

Development #31166

python3: s'assurer que authentic2.exponential_retry_timeout.ExponentialRetryTimeout.seconds_to_wait retourne un entier

Ajouté par Paul Marillonnet il y a environ 5 ans. Mis à jour il y a environ 5 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
06 mars 2019
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

Description

Et là, je ne me souviens plus pourquoi ça ne tourne pas en python3.
Si le relecteur me le demande, je chercherai/relancerai mes tests en local pour en retrouver la raison.


Fichiers


Demandes liées

Lié à Authentic 2 - Development #28276: Fonctionner avec Python3 pour Django1.11Fermé23 novembre 2018

Actions

Révisions associées

Révision 47566924 (diff)
Ajouté par Paul Marillonnet il y a environ 5 ans

python3: make the exp retry timeout 'seconds_to_wait' return an int (#31166)

Historique

#1

Mis à jour par Paul Marillonnet il y a environ 5 ans

#2

Mis à jour par Paul Marillonnet il y a environ 5 ans

#3

Mis à jour par Benjamin Dauvergne il y a environ 5 ans

  • Statut changé de Solution proposée à En cours
  • Assigné à mis à Paul Marillonnet

Parce que None est comparable avec int en python2 et pas en python3, ça marchait ou pas par hasard (en tout cas ça ne traçait pas), remplace juste return par return 0.

#5

Mis à jour par Benjamin Dauvergne il y a environ 5 ans

Rebaser et renommer la branche dont le nom est trop long ça fait planter le serveur LDAP temporaire.

#6

Mis à jour par Benjamin Dauvergne il y a environ 5 ans

  • Statut changé de Solution proposée à En cours
#7

Mis à jour par Paul Marillonnet il y a environ 5 ans

Benjamin Dauvergne a écrit :

Rebaser et renommer la branche dont le nom est trop long ça fait planter le serveur LDAP temporaire.

D'ac, c'est fait et c'est en attente de build.

#8

Mis à jour par Paul Marillonnet il y a environ 5 ans

Bizarre, je ne pensais pas tomber sur ce genre d'erreur depuis l'utilisation de pg_virtualenv introduite dans #31437 :

setting in postgresql.conf.
Error: Port conflict: another instance is already running on /tmp with port 5433
Dropping cluster 9.6/regress ...

#9

Mis à jour par Paul Marillonnet il y a environ 5 ans

  • Statut changé de En cours à Solution proposée

Relancé le build et c'est bon.
Je n'ai pas le temps de creuser l'affaire maintenant pour ce premier build en échec (peut⁻être une option manquante à l'initialisation du pg_virtualenv ?), je reviendrai dessus plus tard, dans un autre ticket sans doute.

#10

Mis à jour par Benjamin Dauvergne il y a environ 5 ans

Paul Marillonnet a écrit :

Relancé le build et c'est bon.
Je n'ai pas le temps de creuser l'affaire maintenant pour ce premier build en échec (peut⁻être une option manquante à l'initialisation du pg_virtualenv ?), je reviendrai dessus plus tard, dans un autre ticket sans doute.

À mon avis il n'y pas grand chose à chercher, il est bien possible que la façon dont pg_virtualenv recherche un port libre ne soit pas adapté à une forte concurrence (et j'ai regardé, il itère depuis 5432, essaye de bind, si ça marche il ferme la socket et prend le port, 100% de chance de faire des collisions régulièrement).

#12

Mis à jour par Benjamin Dauvergne il y a environ 5 ans

  • Statut changé de Solution proposée à Solution validée

Ack.

#13

Mis à jour par Paul Marillonnet il y a environ 5 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit 47566924f9f9a2155b231be69a166db34dd72c4f
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date:   Thu Jan 31 14:20:43 2019 +0100

    python3: make the exp retry timeout 'seconds_to_wait' return an int (#31166)
#14

Mis à jour par Frédéric Péters il y a environ 5 ans

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF