MAINT Extract scenario-history attempt-to-work-unit matching
メンテナーはふだん 2 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 35/100
- issue の種類
- リファクタリング
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 領域
- backend, databases, testing-qa
調査の方向性
Wait for #2766 and read its established query boundary before starting. Then inspect pyrit/memory/memory_interface.py at _build_scenario_history_unit_statement, its subqueries and expressions, and the aggregate builder; run the scenario-history and scenario-run-service tests. Done means the matching logic is extracted without changing result columns, planned/legacy behavior, row counts, or SQLite and SQL Server compatibility.
索引モデルが issue の本文から書いたものです。
説明
Is your feature request related to a problem? Please describe.
MemoryInterface._build_scenario_history_unit_statement() resolves persisted attack attempts to the logical work units used by history counters. It handles planned runs, legacy runs, seed attribution, objective-hash fallback, and deterministic selection between possible matches. This is a substantial query-building responsibility hidden inside the general memory interface.
This is M2 of three scenario-history extraction steps. Not ready yet: depends on #2766. Once that first extraction establishes the internal query boundary, move this matching logic into the same cohesive module. Wait for #2766 to land and confirm that boundary before adding help wanted.
Describe the solution you'd like
Extract only attempt-to-work-unit resolution and its directly related query construction. Keep aggregate arithmetic and aggregate-record conversion in their existing location until the next step.
- Preserve the current query shape and result-column contract consumed by
_build_scenario_history_aggregate_statement(). - Reuse backend-specific plan-unit/seed expansion and attribution expressions through the internal boundary from #2766.
- Keep exact seed-group matching, objective-hash fallback, technique matching, and deterministic ranking in one understandable unit.
- Preserve legacy and mixed batches: runs outside the plan-resolution set retain their current identity/counting behavior.
- Wire the existing aggregate builder to the extracted matching implementation without changing the public memory API.
Acceptance criteria:
- Planned and planless runs produce the same logical unit identities as before.
- Exact seed-group matches retain priority over objective-hash fallback; ambiguous matches retain the existing deterministic ordering.
- Missing or legacy technique attribution preserves current matching behavior.
- Attempts with no matching planned unit remain excluded from planned-run counters; attempts in legacy runs remain counted as before.
- Each attempt contributes the same number of rows, without join-induced duplication.
- Mixed planned/legacy batches and empty plan-resolution sets are covered.
- SQLite and SQL Server backend hooks remain compatible, and existing memory/service history results remain unchanged.
Describe alternatives you've considered, if relevant
Combining matching and aggregate-counter extraction in one change makes the most intricate SQL harder to review. Moving this logic into Python would change query cost and memory use. Prefer a focused SQL-query extraction into the module from #2766, not a separate service or a new attribution policy.
Additional context
Starting points in pyrit/memory/memory_interface.py: _build_scenario_history_unit_statement, _get_scenario_plan_unit_subqueries, _get_scenario_attempt_unit_expressions, and its caller _build_scenario_history_aggregate_statement. Relevant coverage: tests/unit/memory/memory_interface/test_interface_scenario_history.py and tests/unit/backend/test_scenario_run_service.py.
Follow doc/code/framework.md and the applicable database, Python, and test instructions. No database migration, new public API, or changed retry/success policy is intended. The next step will extract aggregate counting and typed aggregate-record construction using this matching boundary.
- 主要言語
- Python
- スター
- 4.5k
- フォーク
- 896
- 平均マージ
- 2日 22時間
- マージ済み PR（30日）
- 214
環境構築
このプロジェクトの環境構築ファイルはまだ確認していません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
microsoft/PyRIT のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
メンテナーはふだん 2 日以内に返信
-
Bug: triage GUI help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
microsoft/PyRIT#2868 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 2 日以内に返信
microsoft/PyRIT の issue をすべて見る
似ている issue
-
[Bug] @deck.gl/arcgis dist import resolves to unpublished @deck.gl/core source path (9.3.11, 9.4.0)オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
workflow: a tick's dispatch counts as 'only this step', and no review self-grants a round unattendedオープンworkflow
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
kristofdegrave/homeassistant-smart-charging#1505 ·
メンテナーはふだん 1 日以内に返信
-
metadata submission
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
canonical/content-cache-operator#163 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
[submission]オープンsubmission
難易度 1/5 1時間未満 初心者へのやさしさ 65/100
leanprover/lean-eval-submissions#1852 ·
メンテナーはふだん 1 日以内に返信