Deep copies and pickling in router validation

[Matteomt]

Hi,

I encountered something unusual while working with litestar~=2.9.0. I’m not ready to report it as a bug just yet, but I do have a question regarding the implementation.

Specifically, I noticed that there’s a deep copy operation at line 311 in litestar/router.py (permalink to current main branch, not different from 2.9.0). It seems that all Router objects are being cloned before use in Litestar.

From git blame I've found the commit e15b93d to introuce the deepcopy.

This stood out to me because it’s not something I would typically expect, and there's no accompanying comment in the code to explain its purpose. It also appears to be a likely cause of an issue I’m experiencing in a particular use case—though I’m still in the process of analyzing this.

Could you provide some insight into the reasoning behind this deep copy?

My specific use case involves usage of a2wsgi and its WSGIMiddleware to allow me adapting a WSGI app to ASGI and mount it as app inside a litestar router (as suggested in #707). WSGIMiddleware uses a thread pool that includes a queue that eventually cannot be pickled (TypeError: cannot pickle '_queue.SimpleQueue' object) leading to uncaught exception at line 311 where the deepcopy is performed.

Thanks!

[Alc-Alc]

There is some information here #3103

[Matteomt]

Thank you!
I found some additional information here: e15b93d

However, there's no mention of copying or deep-copying. The commit notes that similar practices are being used in other parts of the implementation, which is concerning to me—even if it's not causing issues in other parts at the moment.

[provinzkraut]

Could you provide some insight into the reasoning behind this deep copy?

The reason we deep-copy is to circumvent a limitation imposed by a design decision that was made early on, which was to simultaneously allow re-using route handlers (and controllers and routers) while at the same time performing certain tasks in the registration process via mutation of the handler. This means that when you would include a handler multiple times, the subsequent registrations would override these values again, leading to a corrupt configuration.

To solve this problem, the deepcopying was introduced, which, as you noticed, also comes with a bunch of issues.

I am afraid though that there currently isn't a good way around this.

However, I am working on removing the need for copying, by making the handlers purely static configuration objects for version 3. I can't make any promises, but I'm fairly certain that we won't ship it without this change :)