Technique/tactic association pagination reports page length as total
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 68/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- javascript
- 領域
- api
調査の方向性
Start with the pagination logic in app/services/stix/techniques-service.js around line 488 and app/services/stix/tactics-service.js around line 155, then compare it with Workbench's shared pagination behavior. Inspect the schemas for both endpoints and add regression tests for the listed pagination cases in both directions. Done means totals count all filtered associations and stay correct on empty beyond-end pages, with the pagination envelope documented.
索引モデルが issue の本文から書いたものです。
説明
Verified on REST API 4.24.0, commit 69b37fe769e6abe7675d413451a8361aecc36bea.
Reproduction and impact
Create three tactics and three techniques whose kill-chain phases associate every technique with all three tactics. Unpaged reads return three matches in each direction:
GET /api/techniques/TECHNIQUE_ID/modified/MODIFIED/tactics
GET /api/tactics/TACTIC_ID/modified/MODIFIED/techniques
Request each endpoint with limit=1&includePagination=true at successive offsets:
| Offset | Returned items | Actual total | Expected total |
|---|---|---|---|
| 0–2 | 1 distinct item per page | 1 | 3 |
| 3 | 0 | 0 | 3 |
Direct HTTP requests reproduce this with stable unpaged baselines. Filtering and slicing work, but the reported total incorrectly indicates that only one match exists when three are available.
Root cause and expected fix
Both techniques-service.js and tactics-service.js calculate total: pagedResults.length.
Count all filtered associations before slicing, consistent with Workbench's shared pagination behavior. Total should remain three across every page, including an empty beyond-end page. Document the pagination envelope in both endpoint schemas, which currently describe only array responses.
Add regression tests for both directions, page identities, invariant totals, zero matches, nonzero/beyond-end offsets, and limit=0. Related historical pagination feature: closed issue #221.
- 主要言語
- JavaScript
- スター
- 57
- フォーク
- 18
- 平均マージ
- 1日 26分
- マージ済み PR（30日）
- 7
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
mitre-attack/attack-workbench-rest-api のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
-
難易度 3/5 1〜2日 初心者へのやさしさ 74/100
-
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
mitre-attack/attack-workbench-rest-api の issue をすべて見る
似ている issue
-
status/needs-triage type/bug
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
PKU-YuanGroup/OpenAI4S#218 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
debpalash/VoiceStudio#2678 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
メンテナーはふだん 3 日以内に返信
-
Aborting a request that waits for a socket destroys that socket under a later request (socket hang up)対応中かも @vvo が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
ClickHouse/clickhouse-js#1040 ·
メンテナーはふだん 7 日以内に返信