Jobs::DownloadAvatarFromUrl expire

Soutien
1

Bonjour,

Nous venons tout juste de commencer à utiliser avatar_url via DiscourseConnect. Le remplacement de l’avatar est activé et la mise à jour forcée de l’avatar est définie sur true du côté du SSO.

La connexion fonctionne comme prévu, mais les avatars ne sont pas synchronisés. L’activation du mode verbeux pour la connexion SSO affiche tous les paramètres corrects, mais nous recevons systématiquement une erreur de Jobs::DownloadAvatarFromUrl indiquant : “Job exception: execution expired”.

Je ne sais pas ce qui pourrait en être la cause. Je l’ai testé sur une instance Discourse locale et cela a fonctionné sans problème (c’est-à-dire que les avatars ont été téléchargés sans encombre).

Avez-vous des idées sur la façon de résoudre ce problème ou sur sa cause ?

Version actuelle de Discourse : 2.8.0.beta1

env :

hostname	docker-app
process_id	127
application_version	96fd202d9cdac98196abd952c53f583b4af9d8f2
current_db	default
current_hostname	*nom d'hôte correct*
job	Jobs::DownloadAvatarFromUrl
problem_db	default
time	10:58 am
opts	
url	*URL correcte*
user_id	*ID utilisateur correct*
override_gravatar	true
current_site_id	default

backtrace :

/usr/local/lib/ruby/2.7.0/net/http.rb:960:in `initialize'
/usr/local/lib/ruby/2.7.0/net/http.rb:960:in `open'
/usr/local/lib/ruby/2.7.0/net/http.rb:960:in `block in connect'
/usr/local/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
/usr/local/lib/ruby/2.7.0/net/http.rb:958:in `connect'
/usr/local/lib/ruby/2.7.0/net/http.rb:943:in `do_start'
/usr/local/lib/ruby/2.7.0/net/http.rb:932:in `start'
/usr/local/lib/ruby/2.7.0/net/http.rb:606:in `start'
/var/www/discourse/lib/final_destination.rb:443:in `safe_session'
/var/www/discourse/lib/final_destination.rb:394:in `safe_get'
/var/www/discourse/lib/final_destination.rb:133:in `get'
/var/www/discourse/lib/file_helper.rb:56:in `download'
/var/www/discourse/app/models/user_avatar.rb:98:in `import_url_for_user'
/var/www/discourse/app/jobs/regular/download_avatar_from_url.rb:18:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
rails_multisite-3.0.0/lib/rails_multisite/connection_management.rb:80:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
sidekiq-6.2.1/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.2.1/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.2.1/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.2.1/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.2.1/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.2.1/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.2.1/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.2.1/lib/sidekiq/job_retry.rb:112:in `local'
sidekiq-6.2.1/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.2.1/lib/sidekiq.rb:38:in `block in <module:Sidekiq>'
sidekiq-6.2.1/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.2.1/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.2.1/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.2.1/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.2.1/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.2.1/lib/sidekiq/job_retry.rb:79:in `global'
sidekiq-6.2.1/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.2.1/lib/sidekiq/logger.rb:11:in `with'
sidekiq-6.2.1/lib/sidekiq/job_logger.rb:33:in `prepare'
sidekiq-6.2.1/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.2.1/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.2.1/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.2.1/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.2.1/lib/sidekiq/util.rb:43:in `watchdog'
sidekiq-6.2.1/lib/sidekiq/util.rb:52:in `block in safe_thread'

Édition : Il y a suffisamment de RAM et d’espace disque. Je l’ai déjà vérifié.

Édition 2 : Il pourrait en fait s’agir d’un problème de mémoire. Je n’avais pas remarqué la différence entre la mémoire de la machine hôte et la mémoire allouée à Discourse. Nous avons actuellement seulement 512 Mo définis dans notre app.yml, bien que je doive encore vérifier que c’est la cause.

2

Désolé pour la mise à jour tardive.

Je viens enfin de tester avec 1024 Mo et 2048 Mo de mémoire allouée, mais le résultat reste le même. Toute autre suggestion serait grandement appréciée !

Édition : Après avoir relu les journaux encore et encore, j’ai examiné le code du travail et constaté qu’il n’était pas censé être réessayé. Naturellement, c’est exactement ce que j’ai fait. J’ai modifié le fichier et découvert dans Sidekiq que mon problème est en réalité lié à des problèmes de réseau.

Le travail de réessai me renvoie :

Jobs::HandledExceptionWrapper: Wrapped Net::OpenTimeout: execution expired

comme une erreur avec laquelle je peux réellement travailler.

La leçon à retenir pour quiconque dans le futur est : si URI.open(your url).read dans la console Rails ne fonctionne pas, il s’agit probablement d’un problème de réseau Ruby plutôt que d’un problème Discourse. J’ai eu cette idée grâce à Stack Overflow.