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

Loop constructs leak each other's variables as stale or meaningless values

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
静か
技術スタック
python
領域
backend

調査の方向性

まず core/loop_context.py:243 と core/control_system.py:263-267 を読み、次に ForEachTask の展開と create_parallel_queue.on を含む 2 つの for_each パスを追跡します。公開されている bindings を core/loop_contracts.py と比較し、debug-only キーが template bindings ではなく、両方の for_each パスが同じ意図されたサーフェスを公開していれば完了です。

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

説明

Every binding below was observed by executing a pipeline (filesystem tool only, no models) and reading what reached the file.

A construct renders names it has no concept of, and renders them as a plausible-looking value rather than failing:

construct leaked name renders as why it is wrong
for_each body iteration None a for_each has no iteration counter
while body item None a while loop walks no collection
while body length, remaining, has_next, has_prev 0, 0, False, True collection values for a construct with no collection
for_each iterable index, is_first, is_last, position, length, ... 0, True, ... the iterable resolves before the loop exists; these come from a zeroed context that is not the loop's
create_parallel_queue.on index, is_first, is_last, queue_size, parallel_queue_id, parent_task 0, True, ... same: on generates the queue, so nothing per-item exists yet

{{ item }} in a for_each: iterable does error, so the boundary is enforced for exactly one name.

The mechanism for the body cases: ControlSystem._render_task_templates registers every key of metadata["loop_context"] (core/control_system.py:263-267), and that value is LoopContext.get_debug_info() (core/loop_context.py:243) — a dict built for debugging, carrying item_type, nesting_depth, is_current_first and the rest alongside the real bindings. A debug dump became the public template surface by accident.

A narrower list exists 40 lines later (item, index, is_first, is_last, $item, $index) but runs after the wholesale registration and cannot take anything back.

This matters for validation because it makes "what does this construct bind?" unanswerable from the runtime alone: the honest answer is "these six, plus everything in a debug dict". core/loop_contracts.py therefore declares the meaningful bindings and withholds the leaked ones, so validation rejects {{ iteration }} in a for_each. That is a deliberate choice to be stricter than the runtime, and it is the wrong way round — the runtime should stop offering them.

Suggested order:

  1. Give LoopContext an explicit to_template_dict()-style public surface, separate from get_debug_info().
  2. Register only that surface in control_system.py.
  3. Make the two for_each paths (control_system and the ForEachTask expansion) populate the same surface — they currently differ.
  4. Then loop_contracts describes the runtime instead of correcting it.
主要言語
Python
スター
3
フォーク
2
30日以内にマージされた PR はありません

環境構築

はじめの一歩

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

ContextLab/orchestrator のほかの issue

ContextLab/orchestrator の issue をすべて見る

似ている issue

Python の issue をもっと見る

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

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