资源生命周期审计器 - 代码资源获取与释放模式检测工具，优化数据库连接池与作用域管理

ln-654-resource-lifecycle-auditor by levnikolaevich/claude-code-skills

132 周安装量

335 GitHub Stars

安装命令

npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-654-resource-lifecycle-auditor

🇨🇳中文介绍

路径说明： 文件路径（shared/、references/、../ln-*）是相对于技能仓库根目录的。如果在当前工作目录未找到，请定位此 SKILL.md 文件所在的目录，然后向上返回一级以找到仓库根目录。如果缺少 shared/ 目录，请通过 WebFetch 从 https://raw.githubusercontent.com/levnikolaevich/claude-code-skills/master/skills/{path} 获取文件。

资源生命周期审计器（L3 工作器）

专门审计资源获取/释放模式、作用域不匹配和连接池健康状况的工作器。

目的与范围

ln-650 协调器流水线中的工作器 - 由 ln-650-persistence-performance-auditor 调用
审计资源生命周期（优先级：高）
检查会话/连接作用域不匹配、流式端点资源持有、清理模式、池配置
将结构化的发现结果写入文件，包含严重性、位置、工作量、建议
计算资源生命周期类别的合规性得分（X/10）

输入（来自协调器）

必读： 加载 shared/references/audit_worker_core_contract.md。

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

审计规则（优先级：高）

1. 资源作用域不匹配

描述： 通过 DI 注入的资源在整个请求/连接作用域内存在，但仅在其中一小部分被使用。

检测（Python/FastAPI）：

步骤 1 - 查找具有 DB 会话依赖的端点：
- Grep：async def\s+\w+\(.*Depends\(get_db\)|Depends\(get_session\)|db:\s*AsyncSession|session:\s*AsyncSession
步骤 2 - 测量端点主体内会话使用的跨度：
- 计算第一次和最后一次 session\.|db\.|await.*repo 使用之间的行数
- 计算端点函数主体的总行数
步骤 3 - 如果 usage_lines / total_lines < 0.2（会话在函数主体中使用少于 20%）则标记
- 特别是：会话仅在函数开始时使用（身份验证检查、初始加载），但函数继续执行非 DB 工作

检测（Node.js/Express）：

中间件在请求开始时注入 req.db 或 req.knex
Grep：app\.use.*pool|app\.use.*knex|app\.use.*prisma（中间件注入）
路由处理器仅在函数主体的前 20% 使用 req.db

检测（Java/Spring）：

方法上带有 @Transactional 但包含长时间的非 DB 处理
注入了 EntityManager 但仅短暂使用
Grep：@Autowired.*EntityManager|@PersistenceContext + 方法主体分析

检测（Go）：

sql.DB 或 *gorm.DB 传递给处理器，使用一次，然后进行长时间处理
Grep：func.*Handler.*\*sql\.DB|func.*Handler.*\*gorm\.DB

严重： 流式端点（SSE、WebSocket）中的会话作用域不匹配 - 会话被持有数分钟/数小时
高：包含外部 API 调用的端点中的会话作用域不匹配（会话在网络延迟期间被持有）
中：包含超过 50 行非 DB 处理的端点中的会话作用域不匹配

建议： 将 DB 操作提取到作用域函数中；仅在需要时获取会话；使用 async with get_session() as session: 块，而不是端点级别的 DI 注入。

工作量： 中（重构 DI 为作用域获取）

2. 流式端点资源持有

描述： SSE、WebSocket 或长轮询端点在流持续时间内持有 DB 会话/连接。

检测（Python/FastAPI）：

步骤 1 - 查找流式端点：
- Grep：StreamingResponse|EventSourceResponse|SSE|async def.*websocket|@app\.websocket
- Grep：yield\s+.*event|yield\s+.*data:|async for.*yield（SSE 生成器模式）
步骤 2 - 检查流式函数/生成器的作用域中是否有 DB 会话：
- 端点签名中来自 Depends() 的会话 -> 在整个流期间被持有
- 生成器内部来自上下文管理器的会话 -> 作用域内（正常）
步骤 3 - 分析生成器内部的会话使用：
- 如果会话在开始时使用一次（身份验证/权限检查），然后流循环没有 DB 操作 -> 作用域不匹配

检测（Node.js）：

Grep：res\.write\(|res\.flush\(|Server-Sent Events|new WebSocket|ws\.on\(
检查连接/池客户端是否在流循环之前获取且未释放

检测（Java/Spring）：

Grep：SseEmitter|WebSocketHandler|StreamingResponseBody
检查 @Transactional 是否包装了流式方法

检测（Go）：

Grep：Flusher|http\.Flusher|websocket\.Conn
检查 *sql.DB 或事务是否在刷新循环期间被持有

严重： DB 会话/连接在整个 SSE/WebSocket 流持续时间内被持有（高负载下导致池耗尽）
高： DB 连接在长轮询期间被持有（>30 秒超时）

建议： 将身份验证/权限检查移到流开始之前：获取会话，检查身份验证，释放会话，然后开始流式传输。对于流中任何 DB 访问，使用单独的作用域会话。

工作量： 中（重构端点以在流式传输前释放会话）

3. 缺少资源清理模式

描述： 获取资源但没有保证的清理（没有 try/finally、没有上下文管理器、没有 close()）。

检测（Python）：

Grep：session\s*=\s*Session\(\)|session\s*=\s*sessionmaker|engine\.connect\(\) 不在 with 或 async with 内部
Grep：connection\s*=\s*pool\.acquire\(\)|conn\s*=\s*await.*connect\(\) 后面没有 try:.*finally:.*close\(\)
模式：裸 session = get_session() 没有上下文管理器
要排除的安全模式：async with session_factory() as session:、with engine.connect() as conn:

检测（Node.js）：

Grep：pool\.connect\(\)|knex\.client\.acquireConnection|\.getConnection\(\) 在同一函数中没有相应的 .release() 或 .end()
Grep：createConnection\(\) 在 try/finally 中没有 .destroy()

检测（Java）：

Grep：getConnection\(\)|dataSource\.getConnection\(\) 没有 try-with-resources
模式：Connection conn = ds.getConnection() 没有 try (Connection conn = ...) 语法

检测（Go）：

Grep：sql\.Open\(|db\.Begin\(\) 没有 defer.*Close\(\)|defer.*Rollback\(\)
模式：tx, err := db.Begin() 没有 defer tx.Rollback()

高：获取会话/连接但没有清理保证（异常时泄漏）
中：非关键路径中的文件句柄或游标没有清理

例外： 在流式传输/长轮询开始之前获取并释放的会话 -> 跳过。NullPool / pool_size 配置记录为无服务器设计 -> 跳过。

建议： 确保在所有退出路径上清理资源（上下文管理器、try-finally 或框架管理的生命周期）。

工作量： 小（包装在上下文管理器中或添加 defer）

4. 连接池配置缺失

描述： 缺少池健康监控、没有预检、没有回收、没有溢出限制。

检测（Python/SQLAlchemy）：

Grep 查找 create_engine\(|create_async_engine\(：
- 缺少 pool_pre_ping=True -> 未检测到陈旧连接
- 缺少 pool_recycle -> 连接保持时间超过 DB 服务器超时（默认：MySQL 8 小时，PG 无限制）
- 缺少 pool_size -> 使用默认值 5（对于生产环境可能太小）
- 缺少 max_overflow -> 高负载下无限制溢出
- Web 服务中 pool_size=0 或 NullPool -> 无连接池（反模式）
Grep 查找池事件监听器：
- 缺少 @event.listens_for(engine, "invalidate") -> 无法查看连接失效情况
- 缺少 @event.listens_for(engine, "checkout") -> 无法监控连接检出
- 缺少 @event.listens_for(engine, "checkin") -> 无法监控连接归还

检测（Node.js）：

Grep 查找 createPool\(|new Pool\(：
- 缺少 min/max 配置
- 缺少 idleTimeoutMillis 或 reapIntervalMillis
- 缺少连接验证（validateConnection、testOnBorrow）

检测（Java/Spring）：

Grep：DataSource|HikariConfig|HikariDataSource：
- 缺少 leakDetectionThreshold
- 缺少 maximumPoolSize（默认为 10）
- 缺少 connectionTestQuery 或 connectionInitSql

检测（Go）：

Grep：sql\.Open\(：
- 缺少 db.SetMaxOpenConns()
- 缺少 db.SetMaxIdleConns()
- 缺少 db.SetConnMaxLifetime()

高：没有 pool_pre_ping 且没有 pool_recycle（静默提供陈旧连接）
高： Web 服务中没有 max_overflow 限制（高负载下无限制创建连接）
中：缺少池事件监听器（无法查看池健康状况）
中：缺少泄漏检测阈值（Java/HikariCP）
低：池大小为默认值（对于小型服务可能足够）

上下文相关例外：

NullPool 对于无服务器/Lambda 有效
pool_size=5 对于低流量服务可能没问题

建议： 配置 pool_pre_ping=True，pool_recycle < DB 服务器超时，根据预期并发性设置适当的 pool_size，添加池事件监听器进行监控。

工作量： 小（添加配置参数），中（添加事件监听器/监控）

5. 错误路径中未关闭的资源

描述： 跳过资源清理的异常/错误处理路径。

检测（Python）：

查找包含 raise 或 return 但没有事先 session.close()、conn.close() 或 cursor.close() 的 except 块
模式：except Exception: logger.error(...); raise（重新抛出异常但没有清理）
查找具有 DB 会话但未处理 GeneratorExit 的生成器函数：
- Grep：async def.*yield.*session|def.*yield.*session 没有 try:.*finally:.*close\(\)

检测（Node.js）：

Grep：catch\s*\( 块中 throw 或 return 但没有释放连接
模式：pool.connect().then(client => { ... }) 没有 .finally(() => client.release())
没有用于清理的 .finally() 的 Promise 链

检测（Java）：

Grep：catch\s*\( 块中没有 finally { conn.close() }，而连接在 try 中打开
没有对 AutoCloseable 资源使用 try-with-resources

检测（Go）：

Grep：if err != nil \{.*return 在用于资源清理的 defer 语句之前
模式：在 Open() 和 defer Close() 之间进行错误检查并返回而不关闭

严重： 高频端点错误路径中的会话/连接泄漏（池耗尽）
高： API 处理器错误路径中的资源泄漏
中：后台任务错误路径中的资源泄漏

建议： 在可能失败的代码之前使用上下文管理器/try-with-resources/defer；对于生成器，在 yield 周围添加 try/finally。

工作量： 小（在错误路径之前重构获取逻辑）

6. 资源工厂与注入反模式

描述： 使用框架 DI 将短生命周期资源注入到长生命周期上下文中，而不是使用工厂模式。

检测（Python/FastAPI）：

步骤 1 - 查找端点签名中通过 DI 注入的会话：
- Grep：Depends\(get_db\)|Depends\(get_session\)|Depends\(get_async_session\)
步骤 2 - 分类端点生命周期：
- 短生命周期：常规 REST 端点（请求/响应）-> DI 注入正常
- 长生命周期：SSE（StreamingResponse、EventSourceResponse）、WebSocket（@app.websocket）、后台任务（BackgroundTasks.add_task）
步骤 3 - 标记长生命周期端点中的 DI 注入：
- 长生命周期端点应使用工厂模式：在需要时使用 async with session_factory() as session:
- 不应在端点级别使用 session: AsyncSession = Depends(get_session)

检测（Node.js/Express）：

中间件注入的池连接（req.db）在 WebSocket 处理器或 SSE 路由中使用
应使用：在需要时使用 const conn = await pool.connect(); try { ... } finally { conn.release() }

检测（Java/Spring）：

SSE 端点（SseEmitter）的 @Controller 中使用 @Autowired EntityManager
应使用：从 EntityManagerFactory 以编程方式创建 EntityManager

检测（Go）：

*sql.DB 在处理器构造时注入，但应每次操作获取 *sql.Conn

严重： SSE/WebSocket 端点中通过 DI 注入的会话（会话超出预期作用域数个数量级）
高：传递给后台任务的通过 DI 注入的会话（任务超出请求生命周期）

建议： 对于长生命周期上下文使用工厂模式；注入工厂（sessionmaker、pool），而不是会话/连接本身。

工作量： 中（将 DI 从会话更改为会话工厂，添加作用域获取）

必读： 加载 shared/references/audit_worker_core_contract.md 和 shared/references/audit_scoring.md。

必读： 加载 shared/references/audit_worker_core_contract.md 和 shared/templates/audit_worker_report_template.md。

将报告写入 {output_dir}/654-resource-lifecycle.md，其中 category: "Resource Lifecycle" 和检查项：resource_scope_mismatch、streaming_resource_holding、missing_cleanup、pool_configuration、error_path_leak、factory_vs_injection。

向协调器返回摘要：

Report written: docs/project/.audit/ln-650/{YYYY-MM-DD}/654-resource-lifecycle.md
Score: X.X/10 | Issues: N (C:N H:N M:N L:N)

必读： 加载 shared/references/audit_worker_core_contract.md。

不要自动修复： 仅报告
DI 感知： 理解框架依赖注入生命周期作用域（请求、单例、瞬态）
先进行框架检测： 在检查注入模式之前识别 DI 框架
先进行流式检测： 在进行作用域分析之前查找所有流式/长生命周期端点
排除测试： 不要标记测试夹具、测试会话设置、模拟会话
排除 CLI/脚本： DI 作用域不匹配与单次运行脚本无关
工作量现实性： 小 = <1 小时，中 = 1-4 小时，大 = >4 小时
池配置是上下文相关的： NullPool 对于无服务器/Lambda 有效；pool_size=5 对于低流量服务可能没问题
安全模式意识： 不要标记在 async with、with、try-with-resources、defer 内部的资源（已受管理）

必读： 加载 shared/references/audit_worker_core_contract.md。

成功解析 contextStore（包括 output_dir、db_config）
确定 scan_path
检测到 DI 框架（FastAPI Depends、Django 中间件、Spring @Autowired、Express 中间件、Go wire）
清点流式端点
完成所有 6 项检查：
- resource scope mismatch、streaming resource holding、missing cleanup、pool configuration、error path leak、factory vs injection
收集包含严重性、位置、工作量、建议的发现结果
使用惩罚算法计算得分
将报告写入 {output_dir}/654-resource-lifecycle.md（原子性单次 Write 调用）
向协调器返回摘要

审计输出模式： shared/references/audit_output_schema.md

版本： 1.0.0 最后更新： 2026-03-03

🇺🇸English

Paths: File paths (shared/, references/, ../ln-*) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root. If shared/ is missing, fetch files via WebFetch from https://raw.githubusercontent.com/levnikolaevich/claude-code-skills/master/skills/{path}.

Resource Lifecycle Auditor (L3 Worker)

Specialized worker auditing resource acquisition/release patterns, scope mismatches, and connection pool hygiene.

Purpose & Scope

Worker in ln-650 coordinator pipeline - invoked by ln-650-persistence-performance-auditor
Audit resource lifecycle (Priority: HIGH)
Check session/connection scope mismatch, streaming endpoint resource holding, cleanup patterns, pool config
Write structured findings to file with severity, location, effort, recommendations
Calculate compliance score (X/10) for Resource Lifecycle category

Inputs (from Coordinator)

MANDATORY READ: Load shared/references/audit_worker_core_contract.md.

Receives contextStore with: tech_stack, best_practices, db_config (database type, ORM settings, pool config, session factory), codebase_root, output_dir.

Domain-aware: Supports domain_mode + current_domain.

Workflow

MANDATORY READ: Load shared/references/two_layer_detection.md for detection methodology.

Parse context from contextStore
- Extract tech_stack, best_practices, db_config, output_dir
- Determine scan_path
Detect DI framework
- FastAPI Depends(), Django middleware, Spring @Autowired/@PersistenceContext, Express middleware, Go wire/fx
Discover resource infrastructure
- Find session/connection factory patterns (sessionmaker, create_engine, DataSource, pool creation)
- Find DI registration (Depends(), , providers, middleware mounting)

Audit Rules (Priority: HIGH)

1. Resource Scope Mismatch

What: Resource injected via DI lives for entire request/connection scope but is used for only a fraction of it.

Detection (Python/FastAPI):

Step 1 - Find endpoints with DB session dependency:
- Grep: async def\s+\w+\(.*Depends\(get_db\)|Depends\(get_session\)|db:\s*AsyncSession|session:\s*AsyncSession
Step 2 - Measure session usage span within endpoint body:
- Count lines between first and last session\.|db\.|await.*repo usage
- Count total lines in endpoint function body
Step 3 - Flag if usage_lines / total_lines < 0.2 (session used in <20% of function body)
- Especially: session used only at function start (auth check, initial load) but function continues with non-DB work

Detection (Node.js/Express):

Middleware injects req.db or req.knex at request start
Grep: app\.use.*pool|app\.use.*knex|app\.use.*prisma (middleware injection)
Route handler uses req.db only in first 20% of function body

Detection (Java/Spring):

@Transactional on method with long non-DB processing
EntityManager injected but used only briefly
Grep: @Autowired.*EntityManager|@PersistenceContext + method body analysis

Detection (Go):

sql.DB or *gorm.DB passed to handler, used once, then long processing
Grep: func.*Handler.*\*sql\.DB|func.*Handler.*\*gorm\.DB

Severity:

CRITICAL: Session scope mismatch in streaming endpoint (SSE, WebSocket) - session held for minutes/hours
HIGH: Session scope mismatch in endpoint with external API calls (session held during network latency)
MEDIUM: Session scope mismatch in endpoint with >50 lines of non-DB processing

Recommendation: Extract DB operations into scoped function; acquire session only for the duration needed; use async with get_session() as session: block instead of endpoint-level DI injection.

Effort: M (refactor DI to scoped acquisition)

2. Streaming Endpoint Resource Holding

What: SSE, WebSocket, or long-poll endpoint holds DB session/connection for stream duration.

Detection (Python/FastAPI):

Step 1 - Find streaming endpoints:
- Grep: StreamingResponse|EventSourceResponse|SSE|async def.*websocket|@app\.websocket
- Grep: yield\s+.*event|yield\s+.*data:|async for.*yield (SSE generator pattern)
Step 2 - Check if streaming function/generator has DB session in scope:
- Session from Depends() in endpoint signature -> held for entire stream
- Session from context manager inside generator -> scoped (OK)
Step 3 - Analyze session usage inside generator:
- If session used once at start (auth/permission check) then stream loops without DB -> scope mismatch

Detection (Node.js):

Grep: res\.write\(|res\.flush\(|Server-Sent Events|new WebSocket|ws\.on\(
Check if connection/pool client acquired before stream loop and not released

Detection (Java/Spring):

Grep: SseEmitter|WebSocketHandler|StreamingResponseBody
Check if @Transactional wraps streaming method

Detection (Go):

Grep: Flusher|http\.Flusher|websocket\.Conn
Check if *sql.DB or transaction held during flush loop

Severity:

CRITICAL: DB session/connection held for entire SSE/WebSocket stream duration (pool exhaustion under load)
HIGH: DB connection held during long-poll (>30s timeout)

Recommendation: Move auth/permission check BEFORE stream: acquire session, check auth, release session, THEN start streaming. Use separate scoped session for any mid-stream DB access.

Effort: M (restructure endpoint to release session before streaming)

3. Missing Resource Cleanup Patterns

What: Resource acquired without guaranteed cleanup (no try/finally, no context manager, no close()).

Detection (Python):

Grep: session\s*=\s*Session\(\)|session\s*=\s*sessionmaker|engine\.connect\(\) NOT inside with or async with
Grep: connection\s*=\s*pool\.acquire\(\)|conn\s*=\s*await.*connect\(\) NOT followed by try:.*finally:.*close\(\)
Pattern: bare session = get_session() without context manager
Safe patterns to exclude: async with session_factory() as session:, with engine.connect() as conn:

Detection (Node.js):

Grep: pool\.connect\(\)|knex\.client\.acquireConnection|\.getConnection\(\) without corresponding .release() or .end() in same function
Grep: createConnection\(\) without .destroy() in try/finally

Detection (Java):

Grep: getConnection\(\)|dataSource\.getConnection\(\) without try-with-resources
Pattern: Connection conn = ds.getConnection() without try (Connection conn = ...) syntax

Detection (Go):

Grep: sql\.Open\(|db\.Begin\(\) without defer.*Close\(\)|defer.*Rollback\(\)
Pattern: tx, err := db.Begin() without defer tx.Rollback()

Severity:

HIGH: Session/connection acquired without cleanup guarantee (leak on exception)
MEDIUM: File handle or cursor without cleanup in non-critical path

Exception: Session acquired and released before streaming/long-poll begins → skip. NullPool / pool_size config documented as serverless design → skip.

Recommendation: Ensure resources are cleaned up on all exit paths (context managers, try-finally, or framework-managed lifecycle).

Effort: S (wrap in context manager or add defer)

4. Connection Pool Configuration Gaps

What: Missing pool health monitoring, no pre-ping, no recycle, no overflow limits.

Detection (Python/SQLAlchemy):

Grep for create_engine\(|create_async_engine\(:
- Missing pool_pre_ping=True -> stale connections not detected
- Missing pool_recycle -> connections kept beyond DB server timeout (default: MySQL 8h, PG unlimited)
- Missing pool_size -> uses default 5 (may be too small for production)
- Missing max_overflow -> unbounded overflow under load
- pool_size=0 or NullPool in web service -> no pooling (anti-pattern)
Grep for pool event listeners:
- Missing @event.listens_for(engine, "invalidate") -> no visibility into connection invalidation

Detection (Node.js):

Grep for createPool\(|new Pool\(:
- Missing min/max configuration
- Missing idleTimeoutMillis or reapIntervalMillis
- Missing connection validation (validateConnection, testOnBorrow)

Detection (Java/Spring):

Grep: DataSource|HikariConfig|HikariDataSource:
- Missing leakDetectionThreshold
- Missing maximumPoolSize (defaults to 10)
- Missing connectionTestQuery or connectionInitSql

Detection (Go):

Grep: sql\.Open\(:
- Missing db.SetMaxOpenConns()
- Missing db.SetMaxIdleConns()
- Missing db.SetConnMaxLifetime()

Severity:

HIGH: No pool_pre_ping AND no pool_recycle (stale connections served silently)
HIGH: No max_overflow limit in web service (unbounded connection creation under load)
MEDIUM: Missing pool event listeners (no visibility into pool health)
MEDIUM: Missing leak detection threshold (Java/HikariCP)
LOW: Pool size at default value (may be adequate for small services)

Context-dependent exceptions:

NullPool is valid for serverless/Lambda
pool_size=5 may be fine for low-traffic services

Recommendation: Configure pool_pre_ping=True, pool_recycle < DB server timeout, appropriate pool_size for expected concurrency, add pool event listeners for monitoring.

Effort: S (add config parameters), M (add event listeners/monitoring)

5. Unclosed Resources in Error Paths

What: Exception/error handling paths that skip resource cleanup.

Detection (Python):

Find except blocks containing raise or return without prior session.close(), conn.close(), or cursor.close()
Pattern: except Exception: logger.error(...); raise (re-raise without cleanup)
Find generator functions with DB session where GeneratorExit is not handled:
- Grep: async def.*yield.*session|def.*yield.*session without try:.*finally:.*close\(\)

Detection (Node.js):

Grep: catch\s*\( blocks that throw or return without releasing connection
Pattern: pool.connect().then(client => { ... }) without .finally(() => client.release())
Promise chains without .finally() for cleanup

Detection (Java):

Grep: catch\s*\( blocks without finally { conn.close() } when connection opened in try
Not using try-with-resources for AutoCloseable resources

Detection (Go):

Grep: if err != nil \{.*return before defer statement for resource cleanup
Pattern: error check between Open() and defer Close() that returns without closing

Severity:

CRITICAL: Session/connection leak in high-frequency endpoint error path (pool exhaustion)
HIGH: Resource leak in error path of API handler
MEDIUM: Resource leak in error path of background task

Recommendation: Use context managers/try-with-resources/defer BEFORE any code that can fail; for generators, add try/finally around yield.

Effort: S (restructure acquisition to before-error-path)

6. Resource Factory vs Injection Anti-pattern

What: Using framework DI to inject short-lived resources into long-lived contexts instead of using factory pattern.

Detection (Python/FastAPI):

Step 1 - Find DI-injected sessions in endpoint signatures:
- Grep: Depends\(get_db\)|Depends\(get_session\)|Depends\(get_async_session\)
Step 2 - Classify endpoint lifetime:
- Short-lived: regular REST endpoint (request/response) -> DI injection OK
- Long-lived: SSE (StreamingResponse, EventSourceResponse), WebSocket (@app.websocket), background task (BackgroundTasks.add_task)
Step 3 - Flag DI injection in long-lived endpoints:
- Long-lived endpoint should use factory pattern: async with session_factory() as session: at point of need
- NOT session: AsyncSession = Depends(get_session) at endpoint level

Detection (Node.js/Express):

Middleware-injected pool connection (req.db) used in WebSocket handler or SSE route
Should use: const conn = await pool.connect(); try { ... } finally { conn.release() } at point of need

Detection (Java/Spring):

@Autowired EntityManager in @Controller with SSE endpoint (SseEmitter)
Should use: programmatic EntityManager creation from EntityManagerFactory

Detection (Go):

*sql.DB injected at handler construction time but *sql.Conn should be acquired per-operation

Severity:

CRITICAL: DI-injected session in SSE/WebSocket endpoint (session outlives intended scope by orders of magnitude)
HIGH: DI-injected session passed to background task (task outlives request)

Recommendation: Use factory pattern for long-lived contexts; inject the factory (sessionmaker, pool), not the session/connection itself.

Effort: M (change DI from session to session factory, add scoped acquisition)

Scoring Algorithm

MANDATORY READ: Load shared/references/audit_worker_core_contract.md and shared/references/audit_scoring.md.

Output Format

MANDATORY READ: Load shared/references/audit_worker_core_contract.md and shared/templates/audit_worker_report_template.md.

Write report to {output_dir}/654-resource-lifecycle.md with category: "Resource Lifecycle" and checks: resource_scope_mismatch, streaming_resource_holding, missing_cleanup, pool_configuration, error_path_leak, factory_vs_injection.

Return summary to coordinator:

Report written: docs/project/.audit/ln-650/{YYYY-MM-DD}/654-resource-lifecycle.md
Score: X.X/10 | Issues: N (C:N H:N M:N L:N)

Critical Rules

MANDATORY READ: Load shared/references/audit_worker_core_contract.md.

Do not auto-fix: Report only
DI-aware: Understand framework dependency injection lifetime scopes (request, singleton, transient)
Framework detection first: Identify DI framework before checking injection patterns
Streaming detection first: Find all streaming/long-lived endpoints before scope analysis
Exclude tests: Do not flag test fixtures, test session setup, mock sessions
Exclude CLI/scripts: DI scope mismatch is not relevant for single-run scripts
Effort realism: S = <1h, M = 1-4h, L = >4h
Pool config is context-dependent: NullPool is valid for serverless/Lambda; pool_size=5 may be fine for low-traffic services
Safe pattern awareness: Do not flag resources inside async with, with, try-with-resources, defer (already managed)

Definition of Done

MANDATORY READ: Load shared/references/audit_worker_core_contract.md.

contextStore parsed successfully (including output_dir, db_config)
scan_path determined
DI framework detected (FastAPI Depends, Django middleware, Spring @Autowired, Express middleware, Go wire)
Streaming endpoints inventoried
All 6 checks completed:
- resource scope mismatch, streaming resource holding, missing cleanup, pool configuration, error path leak, factory vs injection
Findings collected with severity, location, effort, recommendation
Score calculated using penalty algorithm
Report written to {output_dir}/654-resource-lifecycle.md (atomic single Write call)
Summary returned to coordinator

Reference Files

Audit output schema: shared/references/audit_output_schema.md

Version: 1.0.0 Last Updated: 2026-03-03

Weekly Installs

Repository

levnikolaevich/…e-skills

GitHub Stars

253

First Seen

Mar 3, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykWarn

Installed on

claude-code93

cursor91

codex90

cline89

amp89

github-copilot89

Skills CLI 使用指南：AI Agent 技能包管理器安装与管理教程

44,900 周安装

Find streaming endpoints (SSE, WebSocket, long-poll, streaming response)

Map: which endpoints receive which resources via DI

Scan codebase for violations (6 checks)

Trace resource injection -> usage -> release across endpoint lifetime
Analyze streaming endpoints for held resources
Check error paths for cleanup

Collect findings with severity, location, effort, recommendation

Calculate score using penalty algorithm

Write Report: Build full markdown report in memory per shared/templates/audit_worker_report_template.md, write to {output_dir}/654-resource-lifecycle.md in single Write call

Return Summary: Return minimal summary to coordinator (see Output Format)

Missing @event.listens_for(engine, "checkout") -> no connection checkout monitoring

Missing @event.listens_for(engine, "checkin") -> no connection return monitoring

资源生命周期审计器 - 代码资源获取与释放模式检测工具，优化数据库连接池与作用域管理

🇨🇳中文介绍

资源生命周期审计器（L3 工作器）

目的与范围

输入（来自协调器）

相关 Skills

工作流程

审计规则（优先级：高）

1. 资源作用域不匹配

2. 流式端点资源持有

3. 缺少资源清理模式

4. 连接池配置缺失

5. 错误路径中未关闭的资源

6. 资源工厂与注入反模式

评分算法

输出格式

关键规则

完成定义

参考文件

🇺🇸English

Resource Lifecycle Auditor (L3 Worker)

Purpose & Scope

Inputs (from Coordinator)

Workflow

Audit Rules (Priority: HIGH)

1. Resource Scope Mismatch

2. Streaming Endpoint Resource Holding

3. Missing Resource Cleanup Patterns

4. Connection Pool Configuration Gaps

5. Unclosed Resources in Error Paths

6. Resource Factory vs Injection Anti-pattern

Scoring Algorithm

Output Format

Critical Rules

Definition of Done

Reference Files

最新 Skills