Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

The warm pool learns what to keep warm, with no configuration

オープン
  • 何か問題がありますか？
#771 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
活発
技術スタック
typescript
領域
infrastructure

調査の方向性

Start by locating the warm pool module, its configuration for warmPool.targets, and the worker's lease history and persistence code; the issue does not name file paths or tests. The proposed behavior spans demand learning, persistence across restarts, queue scheduling, capacity budgeting, and status reporting, with several open questions and completion conditions still unwritten. Done means the worker learns and restores warm targets from recent leases, boots queued requests within limits, reports actionable refusals, and preserves explicit target overrides.

索引モデルが issue の本文から書いたものです。

説明

feature:spec

Request: none

Problem

A worker boots nothing ahead of demand unless an operator writes warmPool.targets into the config file and restarts the daemon. Nobody does that, so the first lease of every model, OS and mode on a worker pays a cold boot (about 60 s for an iOS simulator, about 160 s slim, about 70 s for an Android emulator). After a lease ends, the pool reboots the device only if the lease ended less than idle.shutdownAfterMs ago and a slot is free, one boot at a time; the next request often arrives before that lands. A queued request gets a boot only when it is the queue head and a shut-down device already matches; the pool never creates for the queue. The pool learns nothing from what was leased.

Reliability holes found on 2026-10-20 while exploring the module:

  • A boot refused for RAM budget on the queue-head or recently-released rules is declined silently, every pass: no log, no short reason.
  • A target is never reported short while any waiter sits on its platform, even one it cannot serve.
  • A failing target retries forever; each try boots or creates a device.
  • Shut-down devices count against the RAM budget, so ram-budget can be reported with nothing running.
  • Android's quoted boot is always 70 s even when a 4 s snapshot restore is used.
  • lease.granted reports warm both for an instant hit and for a request that waited on a pool boot.
  • History keeps model and platform per request, not osVersion or mode, so nothing can tell which specs are in demand.

Who it is for

The maintainer of a worker that serves parallel coding agents, who installs Simlock and never edits its config. The agents that lease from it, which today wait a cold boot on every new spec and on every burst.

Outcome

With no configuration, a worker keeps warm what it has leased recently: one ready device per recently leased spec, as many as that spec was held at once recently, within the capacity budget, replenished as soon as a warm device is granted, and rebooted after a restart. Queued requests start their boots ahead of their turn. Refusals the pool cannot act on are visible in status. Explicit warmPool.targets stay as an override.

How it works for the user

To be written by the spec session.

Examples

To be written by the spec session.

What could go wrong

To be written by the spec session.

Words used

To be written by the spec session.

Non-goals

  • Fleet-level targets on the gateway. Each worker learns its own demand; the gateway keeps routing by warm hits.
  • Any change to lease identity (fresh keeps costing one create per lease, pre-created as today's targets do).
  • Changing targets without a restart (IDEAS.md, deferred).

Completion conditions

To be written by the spec session.

Open questions

Decided with the maintainer on 2026-10-20, before this issue was opened; the spec session folds them in and does not re-ask:

  • Zero-config behaviour: learned from recent leases only. Nothing is booted before the first lease.
  • Budget: idle warm devices may fill every free running slot, as today.
  • Forgetting: LRU. A learned spec stays warm until a spec leased more recently needs its slot. No time window.
  • Persistence: worker-local, survives a daemon restart.
  • Count per spec: the peak concurrency seen recently for that spec, falling back to one as the peak ages.
  • Queue: the pool boots or creates one device per queued request, not only for the head, within maxConcurrentBoots and the budget.
  • maxConcurrentBoots default derived from CPU count instead of 1.

Still open:

  • The window for "recently" in the peak-concurrency count, and where the learned record lives (state.json or history.db).
  • Whether the reliability holes above are tasks of this feature or separate bugs.
  • Whether lease.granted or the lease result should carry the wait time.

Decisions

To be written by the spec session.

Shared values

To be written by the spec session.

Tasks

To be written by the spec session.

主要言語
TypeScript
スター
20
フォーク
2
平均マージ
8時間 13分
マージ済み PR（30日）
297

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

callstackincubator/simlock のほかの issue

callstackincubator/simlock の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。