Open filippomc opened 1 year ago
@filippomc the listener already is on a separate thread (using async_consume), see https://github.com/MetaCell/cloud-harness/blob/5e5052f3748dc48d954507f339e5b77b1eadd60a/infrastructure/common-images/cloudharness-django/libraries/cloudharness-django/cloudharness_django/services/events.py#L61
Yes the consume is on a different thread, but the initialization of the client isn't, so making the main application thread file failing by default is kafka is not there. That's not necessarily wrong shouldn't be the default behaviour in my opinion as kafka events are usually related to specific features and are preventing/delaying the application startup this way.
Generated applications for django have a default behaviour to sync users which requires kafka and accounts to be fully operative at startup. If they're not fully operative, pods go on a crashloop. This is not ideal because the user facing part of the application does not necessarily requires user login functionality.
Ideally we should set this kind of listeners on a separate pod/container.
A quicker proposal is the following: