Faststream application does not close it in case of error on startup event!

[fraFerrari99]

Hi,
I'm new with Faststream but I'm facing a particular error, that is related to the fact that when, inside the on_startup event, the application faces some errors, it calls the on_shutdown event but does not really close, it remains open! I can add the sys.exit(-1) line of code in the on_shutdown method, but I wanted to ask you why it does not close it at the end of the on_shutdown?

[Lancetnik]

Hi, I'm new with Faststream but I'm facing a particular error, that is related to the fact that when, inside the on_startup event, the application faces some errors, it calls the on_shutdown event but does not really close, it remains open! I can add the sys.exit(-1) line of code in the on_shutdown method, but I wanted to ask you why it does not close it at the end of the on_shutdown?

Can you show me the code, please?

We following snippet works as expected - raises the error to console at startup and downs

from faststream import FastStream
from faststream.rabbit import RabbitBroker

broker = RabbitBroker()
app = FastStream(broker)

@app.on_startup
async def _():
    raise ValueError

[fraFerrari99]

You were speaking about the after_startup method, but I didn't clearly understand how to use it to handle the various possible errors.

[Lancetnik]

@fraFerrari99 after_startup was just a mistake, sorry. I mean on_startup

[Lancetnik]

in case of any errors found after the startup, it doesn't close the application but it just logs the error and the application remains alive while I would like to close it.

FastStream was designed to wait for connection recovery endless time to allow you don't care about infrastructure availability. If you connected at startup and when connection broken, service just waiting for recovery.

[fraFerrari99]

in case of any errors found after the startup, it doesn't close the application but it just logs the error and the application remains alive while I would like to close it.

FastStream was designed to wait for connection recovery endless time to allow you don't care about infrastructure availability. If you connected at startup and when connection broken, service just waiting for recovery.

Our issue was exactly this: the FastStream application was starting before RabbitMQ, and as a result, it was unable to establish a connection. However, the problem persisted even after RabbitMQ was up and running. For this reason we put that code with broker.connect() inside the on_startup in the try/except block with sys.exit(-1) in case of error, because in this way if there's an error and the pod on faststream application is down, K8 will restart it and maybe in that case it will be able to estabilish the connection with RabbitMQ.

[Sehat1137]

@fraFerrari99
Pls, give me MRE of ur code, I have a few ideas why this hapend, but i need check the code