Indeed, the Dockerfile fix is much simpler. Let's hope they will fix the issue upstream (not sure regarding this comment).

We've migrated away from doing that ages ago in favor of app factories, and I'd very much prefer we avoid introducing this again: Side effects such as reading configuration files unconditionally running in importable modules are very bad form.

Seems the simplest solution is to instantiate the wsgi application in swh.*.api.server modules.

Ah, I guess that's the opposite then.

Works fine for me? Are you sure your docker image is up to date?

I was also looking at it.

Hm, i don't know how to close this issue, but it should be closed now.
Thx.

Thx to this change (provided by @olasd) in the swh-docker-dev repository, tasks are exectued:

diff --git a/conf/loader.yml b/conf/loader.yml
index 4a4fb54..0cc07e6 100644
--- a/conf/loader.yml
+++ b/conf/loader.yml
@@ -5,6 +5,7 @@ storage:
 celery:
   task_broker: amqp://guest:guest@amqp//
   task_modules:
+    - swh.loader.package.tasks
     - swh.loader.debian.tasks
     - swh.loader.dir.tasks
     - swh.loader.git.tasks
@@ -16,6 +17,7 @@ celery:
     - swh.deposit.loader.tasks

Let's call it done, event if the small dataset part has not been addressed.

Let's call it done, some minor parts may still need a bit of attention thou

Closing this as I forgot it exists a configuration entry to force the serving of assets by Django (https://forge.softwareheritage.org/rCDFD7b3213293ca1670a738d540cbba05e87e5cf6042).

status:

• runner: fine (no crash, no restart)
• listener: fine (same)
• workers: fine (same)

WIP as the new version has been deployed (runner, listener, workers, etc...)
Let's see if the occurrences still occur.

I've done the upgrade on saatchi and restarted both listener and runner. I've removed the runner restart from the saatchi crontab.

I've pushed an updated kombu to our repository.

bunch of celery workers (loader*, lister*) indeed have a ConnectionResetError stacktrace (not necessarily the same):

As per our pair-programming yesterday, I think we reproduce this in production now (with the runner at least).

I confirm that I do not see ConnectionResetError: [Errno 104] Connection reset by peer and BrokenPipeError: [Errno 32] Broken pipe so far in the runner logs with kombu from git's master.