This message was deleted.

hey, are you thinking about debugging the runnable?

yes. I want to be able to debug the full path of the request. from the server receiving a request to the runnable and to the response. just like a regular flask server. I can debug if I run the server

.init_local()

but I can’t make the full server working with a debugger.

I will discuss with the team to about this usecase

@Pavel Schudel What would be different between doing

.init_local()

and running a separate runner, in terms of debugging?

init_local

will load the model memory, whereas runner is distributed by default. What this means is when running in the serving environment, BentoML will provisioned resource and initialize model correctly within a distributed env (such as k8s)

@Aaron Pham I understand but why do we want to debug at distributed env, should we debug behavior's using in memory using

init_local

, if in-memory works, so would the distributed system right?

Usually, thats the

init_local

workflow, where you debug it locally. What Pavel is asking is that he wants to debug within the server

I recommended that solution, I'm trying to understand, what is Pavel's use case here, does this solution of `uvicorn`and `asgi_app`work for his debugging needs?

sorry for the late response. well, the optimal scenario is the debug everything as close to production as possible. will the least amount of non production debugging code. the reason is when a bug happens in production, I need to simulate the request separately with .init_local(), and not debug it in the natural application ecosystem. (the service is called by another service). so every bug take a lot more time to debug then a regular flask server.