mytglib 2.0.4 → 2.0.5

package/README.md

@@ -236,6 +236,7 @@ const pool = await createPhoneStatusPool({
   databasePath: resolve(".data/phone-status-pool/pool.sqlite"),
   minWarmSlots: 10,
   retryWarmSlots: 200,
+  maxConcurrentChecks: 256,
 });
 
 const account = await pool.importAccount({
@@ -288,8 +289,21 @@ Pool 的 PRIMARY 策略硬上限固定为 `minWarmSlots * 5`，加上 `retryWarm
 事件循环压力评估限制。忙碌槽位超过当前连接数一半时，Pool 会在资源允许的情况下异步提高目标槽位；
 高峰过后，弹性槽位连续空闲 10 分钟才进入回收，并且每 30 秒最多回收一个，避免连接数瞬间震荡。
 进入 `PRESSURED` 时，Pool 会先回收 PRIMARY 弹性槽，并保留当前资源上限能够承载的基础 PRIMARY
-和独立 RETRY 槽；若上限不足，则优先保证 PRIMARY，按剩余容量降低 RETRY 数。只有进入
-`CRITICAL` 时才暂停建连并回收全部 RETRY 和 PRIMARY 弹性槽。
+和独立 RETRY 槽；若上限不足，则优先保证 PRIMARY，按剩余容量降低 RETRY 数。
+单次事件循环尖峰只触发 `PRESSURED`，连续 3 次成功采集的严重样本才进入软 `CRITICAL`，连续 2 次健康样本恢复；采样失败会打断连续计数。
+`resource.hardCritical` 区分内存/堆硬危险与事件循环软压力：软 `CRITICAL` 暂停建连、保留就绪主备槽并
+以 10% 检测预算继续服务，不因 PRIMARY 未达到配置目标而回收已有 RETRY；暂停预热期间有效目标按实际存量显示。
+硬危险立即拒绝新检测并逐步释放空闲连接，可低于配置的最小暖槽数。
+压力回收每秒最多启动一个，不中断正在使用的槽。`resource.pressureReasons` 报告具体压力原因，
+`resource.capacityLimitingFactor` 单独报告连接容量瓶颈，避免把“目标未预热满”当成“资源未承压”。
+监控采样失败时停止新建连接、缩小检测预算，连续 3 次失败后拒绝新检测；运行期单次采样最多等待 3 秒，
+未完成的采样不会重复启动。`lastSuccessfulSampleAt` 用于识别陈旧数据。
+
+`maxConcurrentChecks` 默认 `256`，限制未完成的不同手机号共享检测任务（包含等待 READY 的任务）。
+`PRESSURED` 下预算为 50%，软 `CRITICAL` 为 10%，硬危险为 0；达到上限立即返回 `POOL_QUEUE_FULL`。
+缓存命中和相同手机号的跟随者不新增共享检测名额。HTTP 层仍需独立限制总请求数与每用户并发，
+防止大量跟随者占满 Web 进程。预热只排入最多两倍握手并发的连接任务，分别计算 PRIMARY/RETRY 缺口，主槽富余不会抵消重试槽缺口。
+READY 槽按风险/最近使用时间由索引优先队列选择，不再逐请求排序全部连接。
 当总连接上限高于 `minWarmSlots` 时，Pool 会在这个上限内部为导入和待机账号自检保留 1 个临时
 管理连接位；该预留不会突破 PRIMARY 策略上限与 `retryWarmSlots` 之和。若资源上限已经低到不高于
 最小暖槽数，管理建连会返回 `POOL_BUSY`，优先保护正在提供服务的暖槽。
@@ -300,6 +314,7 @@ Pool 的 PRIMARY 策略硬上限固定为 `minWarmSlots * 5`，加上 `retryWarm
 const response = await pool.checkPhoneStatus({
   phone: "+12025550123",
   abortSignal: new AbortController().signal,
+  deadlineAt: Date.now() + 13_000, // 可选：调用方等待的绝对期限
 });
 
 console.log(response.status, response.waitTime, response.error);
@@ -345,6 +360,11 @@ Telegram 原始 `code = 420` 和错误文本。
 `abortSignal` 只取消当前调用方等待，并以 `OTHER_ERROR` 返回取消原因；它不会中断已经启动的
 single-flight RPC。即使当前只有一个等待者，后台检测仍可完成并写入明确结果缓存。调用开始前已经
 取消的 signal 会在读取缓存前返回，不会命中旧结果或启动新 RPC。
+`deadlineAt` 同样只限制当前调用方等待，不会缩短同号码其他调用者共享任务的 14 秒内部预算。
+调用方离开后，内部任务仍占用 `maxConcurrentChecks` 名额直至完成。
+普通检测的统计增量每秒合并写入 SQLite，并在候选选择和关闭时刷新；异常退出可能丢失最后
+约一秒统计，账号冷却/隔离等调度状态仍立即持久化。统计写失败保留待写增量并报告后台错误。
+管理查询直接叠加待写统计、不强制刷新；仓储新增不会因无关统计刷新失败出现“已落库却抛错”，删除和冷却/隔离状态落盘也不受统计刷新阻断。候选选择仍要求统计刷新成功以保持排序；完整导入流程中的必要写入失败时仍会回滚导入。
 
 按照当前业务规则，`403 RECAPTCHA_CHECK_signup`（含 site key 后缀）直接判定为
 `PHONE_NUMBER_NO_OCCUPIED`。Pool 不求解、不重放 challenge；它会回收触发 challenge 的槽位并从库存
@@ -352,6 +372,15 @@ single-flight RPC。即使当前只有一个等待者，后台检测仍可完成
 
 ### 管理与运行状态
 
+大库存管理列表可调用 `await pool.listAccountsPage({ page: 1, pageSize: 20, phone: "", runtimeStatus: "READY" })`，
+返回 `{ accounts, total, page, pageSize }`。`pageSize` 为 1–100，页码越界时回到最后一页，筛选后的账号投影不读取
+auth key 或 session metadata。原 `listAccounts()` 继续兼容。`getStatus()` 从轻量状态索引汇总，包含
+`resource`、`roles`、`queues` 和 `admission`，不读取全量会话。
+
+本机 mock Telegram + 真实 SQLite 的容量测量见 [基准说明](docs/phone-status-pool-benchmark.md)。
+该基准只能验证调度开销与预算上限，真实吞吐还需在目标硬件、真实网络延迟和账号限流条件下测量。
+
+
 ```js
 const accounts = await pool.listAccounts();
 const detail = await pool.getAccount(account.accountId);