docs(P-006): reconcile OQ#3 — directly-injected IServiceScopeFactory is modelled (Closes #200)#213
Conversation
…is modelled #200 ("recognize directly-injected IServiceScopeFactory as a positive signal", P-006 OQ#3): the functional deliverable already shipped in PR #126 and is CI/test-pinned on main. The correct scope-per-operation pattern (resolve inside the scope, use, discard) is silent BY CONSTRUCTION — the extractor emits `scope_cached` only for a value stored into a FIELD — and caching a scope-resolved scoped service into a field is DI005. There is no separate approval marker to add: the "positive signal" is the ABSENCE of a captive fact. Recognising the factory injection as licence to suppress other captive findings would be wrong (a singleton that also injects a scoped service directly is still DI001). Doc-reconciliation only, no code change: - P-006-di-lifetimes.md OQ#3: "not yet implemented" -> resolved, with the mechanism and the ScopeUsingService/ScopeCachingService pins. - di-captive-extractor.md: add the missing DI005 section (the doc jumped DI004 -> Next); drop the now-shipped item from Next; record the genuinely-deferred escape shape (scope-resolved scoped that escapes via return/ref/out/arg) as a candidate. - ROADMAP.md milestone 3: strike the done item from Remaining, leaving only the dynamic-registration non-goals. Verified: DiCaptiveSample.cs through the real extractor+core gives DI005 on ScopeCachingService + UnitOfWorkCachingService, silence on ScopeUsingService + ClockCachingService; contrib selftest 16/16; ruff clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cg6DVXahkyY68Ruu7f76rG
|
Warning Review limit reached
Next review available in: 52 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
2 participants
Что и зачем
#200 просил «recognize directly-injected
IServiceScopeFactoryas a positive signal» (P-006 OQ#3). Эмпирическая проверка показала, что функциональный деливерабл уже поставлен в PR #126 и запинен CI + юнит-тестами наmain: корректный scope-per-operation паттерн молчит by construction (экстрактор эмититscope_cachedтолько на store-в-поле), а кэширование scope-resolved scoped-сервиса в поле — это DI005. Отдельного «флажка одобрения» добавлять не нужно и не следует: «positive signal» — это отсутствие captive-факта, а глушить другие captive-находки по факту инъекции фабрики было бы неверно (singleton, который вдобавок инжектит scoped напрямую, всё равно DI001). Поэтому деливерабл — сверка документации с реальностью, без изменений кода.Доказательство (прогон
DiCaptiveSample.csчерез настоящий экстрактор + ядро на текущемmain):ScopeCachingServiceIServiceScopeFactory→ resolve → кэш в полеUnitOfWorkCachingServiceScopeUsingServiceIServiceScopeFactory→ resolve в локал, use, disposeClockCachingServiceЗапинено:
ci.yml:691–726(DI-контраст) иtests/test_ownir.py:946–1027. Механизм в экстракторе —Program.cs:3166(распознаваниеIServiceScopeFactoryкак scope-creator) +ScopeCachedTypes(эмиссия только на field store).Тип изменения
Как проверено
ruff check .— clean (docs не трогают код; run_tests.py/mypy без изменений)python scripts/validate_contrib.py --selftest→ 16/16dotnet run --project frontend/roslyn/OwnSharp.Extractor -- DiCaptiveSample.cs | python -m ownlang ownir— таблица вышеСвязанные issue
Closes #200. Refs #126 (где деливерабл фактически поставлен).
Что именно поменялось (docs-only)
P-006-di-lifetimes.mdOQ#3: «not yet implemented — a natural future extension» → resolved (shipped in feat(extractor): emit fresh-returning factory facts — D5.2 interprocedural leaks on real C# #126), с механизмом и пинамиScopeUsingService/ScopeCachingService.di-captive-extractor.md: добавлена отсутствовавшая секция DI005 (док прыгал с DI004 сразу в «Next»); убран уже поставленный пункт из «Next»; записан действительно отложенный кандидат — scope-resolved scoped, убегающий из scope черезreturn/ref/out/аргумент (сегодня молчит precision-safe, нужен flow-aware срез, не store-site модель).ROADMAP.mdmilestone 3: строка вычеркнута из Remaining, остаются только динамические регистрации (явные non-goals).Чеклист
test_ownir.py; настоящий PR — сверка документации, новых фикстур не требуетdocs:)🤖 Generated with Claude Code
Generated by Claude Code