Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Scenario progress double-counts an attack result after its timestamp is bumped

Closed
  • Is something wrong?
#3,183 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

@ManoharPaturi is already working on this.

Since Oct 13, 2026.

  • #3184 by @ManoharPaturi — open

Assessment

Difficulty
3/5
Estimated time
Half a day
Newbie friendliness
25/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
backend

Research direction

Start in ScenarioProgressReadModel._hydrate_new_deltas_async, where each page is appended with entry.deltas.extend(page) and nothing is deduplicated by attack_result_id. Then read get_scenario_attack_result_deltas_async to see how the keyset cursor over (timestamp, id) re-emits bumped rows. A re-emitted delta should update the cached copy of that attempt, not add a second one. Linked PR #3184 is already open against this, so check it before starting.

Written by the indexing model from the issue text.

Description

Describe the bug

The scenario progress read model double-counts an attack result whose row timestamp is later bumped.

get_scenario_attack_result_deltas_async pages rows in ascending keyset order over (timestamp, id), so any row whose timestamp moves forward compares greater than the stored cursor and is emitted again. That happens today: AttackService.update_attack_async and remove_human_score_async write "timestamp": datetime.now(UTC) on every edit, and promote_attack_conversation rewrites timestamps too.

ScenarioProgressReadModel._hydrate_new_deltas_async handles each page with entry.deltas.extend(page) and no dedup by attack_result_id, so the re-emitted row is appended as a second copy of the same attempt. The snapshot's results then contains the same attack twice, which inflates per-unit attempt counts and retry pressure for the lifetime of the cache entry.

Steps/Code to Reproduce
  1. Poll GET /scenarios/{id}/progress once so the read model caches the run's deltas and cursor.
  2. Edit any attack result that belongs to that scenario (for example PUT /attacks/{attack_result_id}), which bumps the row's timestamp.
  3. Poll the scenario progress endpoint again.

The storage feed re-emits the edited row (keyset timestamp > cursor), and the read model appends it again.

Minimal reproduction against the read model:

memory.get_scenario_attack_result_deltas_async = AsyncMock(
    side_effect=[([delta], False), ([bumped_delta_with_same_id], False)]
)
read_model = ScenarioProgressReadModel(memory=memory)
first = await read_model.get_snapshot_async(scenario_result_id="run", ...)
second = await read_model.get_snapshot_async(scenario_result_id="run", ...)
# second.results holds the same attack_result_id twice
Expected Results

A re-emitted delta updates the already cached copy of that attempt instead of adding a second one.

Actual Results

The same attack result id appears twice in the snapshot results, inflating attempt counts.

Screenshots

N/A

Versions

OS: macOS
Python version: 3.14
PyRIT version: installed from main (66c41fa)

Dominant language
Python
Stars
4.6k
Forks
944
Avg merge
2d 16h
Merged PRs (30d)
350

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/PyRIT

All issues in microsoft/PyRIT

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.