Context
Discovered during test run in the #24 PyPI propagation delay implementation session.
Description
tests/test_init_integration.py::test_init_full_flow_with_docker fails when run explicitly (pytest -m slow). The test calls codegraph init --yes, asserts returncode == 0 (passes), then checks docker ps for the expected container name — but the container is not present.
Error observed:
AssertionError: assert 'cognitx-codegraph-test_init_full_flow_with_docke0-4d7606fa' in 'twenty-dev-redis-1\ntwenty-dev-db-1\ncodegraph-neo4j\n...'
The test is marked @pytest.mark.slow and excluded from the default pytest run via addopts = "-m 'not slow'" in pyproject.toml, so it has been silently broken without blocking CI.
Suggested approach
- Run
codegraph init --yes manually in a tmp dir and inspect whether the container actually starts and stays up
- Check if
docker compose up -d in init is non-blocking and the container exits immediately with an error
- Add a short readiness poll (e.g. wait for Neo4j bolt port) before the
docker ps assertion
- Consider whether the
fake_monorepo fixture produces a path whose name truncation changes the expected container hash
Context
Discovered during test run in the #24 PyPI propagation delay implementation session.
Description
tests/test_init_integration.py::test_init_full_flow_with_dockerfails when run explicitly (pytest -m slow). The test callscodegraph init --yes, assertsreturncode == 0(passes), then checksdocker psfor the expected container name — but the container is not present.Error observed:
The test is marked
@pytest.mark.slowand excluded from the defaultpytestrun viaaddopts = "-m 'not slow'"inpyproject.toml, so it has been silently broken without blocking CI.Suggested approach
codegraph init --yesmanually in a tmp dir and inspect whether the container actually starts and stays updocker compose up -dininitis non-blocking and the container exits immediately with an errordocker psassertionfake_monorepofixture produces a path whose name truncation changes the expected container hash