Repository navigation
FEAT GUI: Add memory-backed dataset summary API #2746
Description
Is your feature request related to a problem? Please describe.
The dataset endpoint currently returns names. The planned dataset cards also need counts, modalities, harm categories, and loaded/source information without retrieving every prompt or fetching remote datasets.
This is work item 1 of 17 in #2744 and the first contributor-ready item.
Describe the solution you'd like
Extend the dataset service and typed REST models with a read-only, memory-backed summary contract. Preserve compatibility for existing clients that consume items[].name. Keep provider availability separate from the population actually loaded in memory.
Scope:
- Enumerate stored dataset names and provide a deterministic representation for unnamed seeds rather than losing them.
- Define and document counts for logical examples, seed/prompt pieces, and objectives. A linked text/image example must not be reported as two independent examples.
- Aggregate existing modalities and harm categories. Represent missing metadata explicitly; an absent harm label does not mean safe.
- Provide stable dataset selection keys and distinguish loaded counts from unknown/estimated provider metadata. Do not assume matching dataset names prove identical provider provenance.
- Use aggregate/projection queries rather than loading all seed values to build cards. Add only narrow read-query helpers in memory if needed, portable across SQLite and Azure SQL.
Acceptance criteria:
- An empty memory returns a valid empty response.
- Mixed seed types, multimodal groups, unnamed seeds, and missing metadata produce correct, documented summaries.
- Listing does not call provider fetch methods, download assets, mutate seeds, or invoke a model.
- Existing name-list consumers remain compatible.
- Tests cover the response contract, count semantics, and side-effect-free behavior without credentials or network datasets.
Describe alternatives you've considered, if relevant
Do not create a dataset table, add schema migrations, materialize every seed in the service, or fetch providers just to determine card counts. Provider descriptors and explicit loading are later items.
Additional context
Start with pyrit\backend\routes\datasets.py, pyrit\backend\services\dataset_service.py, pyrit\backend\models\datasets.py, MemoryInterface seed queries, and tests\unit\backend\test_dataset_service.py. Coordinate with #2735 rather than duplicating unloaded-dataset sizing work.
Read doc\code\framework.md and applicable Python, model, database, and test instructions. This item establishes the API contract used by the next browsing and card issues. Only this item is initially help wanted; the parent describes promotion of later items.
Activity
jacksonsr451 commentedon Sep 24, 2026
Hi Roman Lutz (@romanlutz), I'd like to work on this issue.
I've reviewed the scope and acceptance criteria, including the related context in #2744 and the coordination note for #2735.
My plan is to:
items[].nameconsumers;Before implementing, I'll review
doc/code/framework.mdand the applicable Python, model, database, and testing guidance, as well as the existing implementations indatasets.py,dataset_service.py, the dataset REST models, and the relevantMemoryInterfaceseed queries.If no one is currently working on this, I'd be happy to take it.
romanlutz commentedon Sep 24, 2026
Jackson Severino da Rocha (@jacksonsr451), thanks for offering to help and for outlining your approach. This summary API has already been implemented in #2762, which has merged into
main. The PR referenced this issue without a closing link, and I missed closing it and removinghelp wanted. Sorry for the confusion.I'm closing this issue as completed; there is no need to implement the summary API again. The next available item is #2748, the paginated seed browsing API, now marked
help wanted. If you'd like to work on that, please comment on #2748 so we can coordinate before you start. It builds on the summary contract from #2762.jacksonsr451 commentedon Sep 24, 2026
Thanks for the clarification, Roman. No problem.
I'll take a look at #2748 and the implementation from #2762 to understand the summary contract it builds on. I'll comment on #2748 before starting any implementation so we can coordinate the work there.
Thanks for pointing me to the next available item.