Resource finalizer never called in VS Code debugger

[chrisk314]

Hi, I'm seeing some strange behaviour when attempting to use Resource type providers during debug sessions in VS Code. From adding both print statements and breakpoints into the code, it's clear that the code in the finally block is never reached when running in debug mode in VS Code. Running the code normally, i.e., as a python script in a terminal, I can see the print outputs as expected.

There is a minimal reproducible example below. In this case, it's not an issue; however the actual code where I noticed this problem launches a child process which must be terminated in the finally section (it runs an infinte loop - it's a message proxy). Failure to evaluate this finally block in VS Code debug mode causes test cases to run indefinitely. I can add similar code into a pytest conftest fixture and it works fine. It's worth mentioning that running the script inside VS Code but not in debug mode also works fine.

I'm running...
python: 3.12.8
that-depends: 1.27.0
vs code: 197.0
os: Windows 11 with WSL2 Ubuntu 24.04

# that_depends_example.py

import typing as _t

from that_depends import BaseContainer, Provide, inject
from that_depends.providers import Resource


def say_hello_goodbye() -> _t.Iterator[None]:
    try:
        print(f"Hello!")
        yield None
    finally:
        print(f"Goodbye!")


class DI(BaseContainer):
    """`DI` is a dependency injection container for plugboard."""

    say_hello_goodbye: Resource[None] = Resource(say_hello_goodbye)


@inject
def require_resource(resource: None = Provide[DI.say_hello_goodbye]) -> None:
    print("With resource...")


if __name__ == "__main__":
    require_resource()

VS Code launch config for convenience.

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "that_depends_debug_bug",
            "type": "python",
            "request": "launch",
            "program": "${workspaceFolder}/that_depends_example.py",
            "console": "integratedTerminal",
            "justMyCode": false,
        },
    ]
}

[lesnik512]

@chrisk314 Hi!

In order to finalize resource you need to call DI.tear_down()

await DI.tear_down()

If you want to finalize after each call of require_resource, you can try using ContextResource

[alexanderlazarev0]

@lesnik512 I think we were a little pre-mature with converting this to a discussion. I have analyzed the issue and can reproduce this behavior. Indeed, similar behavior exists on 2.0.0 and on there it is inconsistent depending on if the provider is defined in a Container or not.

@chrisk314

• Firstly, the Resource provider is just like a Singleton but for context managers in that-depends. That means the resolved value is cached and will be reused whenever you re-resolve the provider. Therefore, you should not expect it to finalize without you actually telling it to (more on that later).
• Now, as to why you are seeing this behavior: You are seeing the "goodbye" message not because of that-depends logic, but because python's garbage collector finalizes the resource at some point after the provider is dereferenced. This is "inconsistent" and should not be relied upon. It is also not debuggable in any standard way, hence why you were not able to do so.
• In the other piece of code you mentioned, the resource provider either:
  • Was not dereferenced at all (so not garbage collected)
  • Was garbage collected, but at a different point when correct finalization was no longer possible.

Quick Solution

I see that in the example all the code is sync and I have realized we did not expose the sync_tear_down API to Resource providers. We can turn this into a feature request. Right now, a workaround without using asyncio.run would be:

say_hello_goodbye._context.sync_tear_down()

This will also make the finalization debuggable :)

Another solution:

I would recommend using a ContextResource after an upgrade to 2.0.0 since you can manage finalization properly and 2.0.0 provides lots of tools to do so, it will also work with 1.27.0 but is slightly dependent on the rest of your setup. ContextResource documentation

Let us know if this helps.

[chrisk314]

@alexanderlazarev0 thank you for looking into this and providing a detailed explanation and possible solutions. Much appreciated. It makes sense that there should be some tear down to ensure the iterator is invoked again to evaluate the finally block. I guess the inconsistency between running in debug mode or not is, as you say, due to differences in how code is executed, reference counted, and garbage collected etc; therefore not something to be relied upon.

One comment I would add is that the existence of the tear_down methods, and the necesity of their usage, for the Container or Resource abstractions in the examples and quick overviews in the docs is not so obvious. Searching for tear_down produces no results and searching for tear down produces just a couple of results. May be worth making the need to call tear_down more obvious in the docs.

I will look into the ContextResource in v2.0.0 and see if that can help in my case. Any suggestion for a potential pattern in my use-case would be helpful. Often when using a DI container we're running an application that has a well defined lifecycle such as a web server or a cli entrypoint. In these instances, our entrypoint controls the lifecycle, initiating some context and tearing down on exit.

In my case, the DI container is being used in a python library. I'm creating the DI container in a python-lib/di.py module and then using the objects throughout the python-lib code. In this case, would you have any suggestions for how the call to DI.tear_down should be orchestrated? At some point the code calling my lib will exit, but my lib code is not involved in the exit process of the calling code, nor would I want the calling code to need to call DI.tear_down directly.

Perhaps there is a solution involving keeping a reference to a contextlib.ExitStack and calling close on this in the Container.__del__ method... These things seem to be quite tricky and unreliable in Python!

[alexanderlazarev0]

@chrisk314

One comment I would add is that the existence of the tear_down methods, and the necesity of their usage, for the Container or Resource abstractions in the examples and quick overviews in the docs is not so obvious. Searching for tear_down produces no results and searching for tear down produces just a couple of results. May be worth making the need to call tear_down more obvious in the docs.

Thank you for the feedback, we have been working on our documentation, unfortunately we haven't gotten to these providers yet. I have now hopefully addressed the documentation issues in #161, so the documentation should be better with the next release.

I have also implemented sync tear down logic for relevant providers in #161 so now the intended way to finalize Resource providers should be possible:

Container.sync_resource.sync_tear_down() # as of that-depends>=2.1.0

I will look into the ContextResource in v2.0.0 and see if that can help in my case. Any suggestion for a potential pattern in my use-case would be helpful. Often when using a DI container we're running an application that has a well defined lifecycle such as a web server or a cli entrypoint. In these instances, our entrypoint controls the lifecycle, initiating some context and tearing down on exit.

In my case, the DI container is being used in a python library. I'm creating the DI container in a python-lib/di.py module and then using the objects throughout the python-lib code. In this case, would you have any suggestions for how the call to DI.tear_down should be orchestrated? At some point the code calling my lib will exit, but my lib code is not involved in the exit process of the calling code, nor would I want the calling code to need to call DI.tear_down directly.

I hope I have understood your use case correctly, so here are some examples:

Table of Contents

• lib/di.py
• lib/entry.py
• main.py

File: lib/di.py

import typing
from datetime import datetime

from that_depends import BaseContainer, providers


def create_sync_resource() -> typing.Iterator[datetime]:
    print("Initiating sync resource")
    yield datetime.now()
    print("Destructing sync resource")


class Container(BaseContainer):
    """Container for the application."""

    default_scope = None

    context_resource = providers.ContextResource(create_sync_resource)
    another_context_resource = providers.ContextResource(create_sync_resource)
    resource = providers.Resource(create_sync_resource)

File: lib/entry.py

from datetime import datetime

from lib.di import Container
from that_depends import Provide, container_context, inject


@Container.context_resource.context
def entry_point_with_wrapper() -> None:
    library_code_with_context_resource()


def entry_point_with_explicit() -> None:
    with Container.context_resource.sync_context():
        library_code_with_context_resource()


@container_context(Container.context_resource, Container.another_context_resource)  # make sure `that-depends>=2.1.1`
def entry_with_multiple_resources_wrapped() -> None:
    library_code_with_context_resource()


def entry_with_multiple_resources_explicit() -> None:
    with container_context(Container.context_resource, Container.another_context_resource):
        # this will only call initialization and finalization of `another_context_resource` if it actually
        # gets used in the rest of the code
        library_code_with_context_resource()

def entry_with_multiple_resources_container() -> None:
    with Container.sync_context():
        library_code_with_context_resource()


def entry_point_with_resource() -> None:
    library_code_with_resource()
    Container.resource.sync_tear_down()


@inject
def library_code_with_context_resource(time: datetime = Provide[Container.context_resource]) -> None:
    print(time)


@inject
def library_code_with_resource(time: datetime = Provide[Container.resource]) -> None:
    print(time)

File: main.py

from lib.entry import (
    entry_point_with_explicit,
    entry_point_with_resource,
    entry_point_with_wrapper,
    entry_with_multiple_resources_explicit,
    entry_with_multiple_resources_wrapped, entry_with_multiple_resources_container,
)


def calling_code() -> None:
    entry_point_with_wrapper()
    entry_point_with_explicit()
    entry_point_with_resource()
    entry_with_multiple_resources_wrapped()
    entry_with_multiple_resources_explicit()
    entry_with_multiple_resources_container()


if __name__ == "__main__":
    calling_code()

You can also achieve similar behavior with scopes

Perhaps there is a solution involving keeping a reference to a contextlib.ExitStack and calling close on this in the Container.del method... These things seem to be quite tricky and unreliable in Python!

I would recommend avoiding any kind of logic related to __del__, others have explained it much better than i could