Summary
When the seed document yields zero entities matching the generated ontology, the backend fails fast (~40 ms) with an explicit error — but the frontend never surfaces it. The UI stays in a perpetual "Config generating…" progress state (with an unrelated-looking Load error 500 in the console), which reads as a hang. In an earlier run we waited 70+ minutes on what we then believed was a backend deadlock; source-level and network-level re-testing showed it was a UI-layer artifact over a clean, immediate backend failure.
Reproduction
- Start a new simulation with a seed document that produces no extractable entities for the generated ontology (we used a Latin lorem-ipsum document; the config-generation step confabulated a 10-type policy ontology from the prompt, and entity extraction then matched nothing).
- Proceed to agent generation.
- Observe the network tab: both
/prepare and /generate-profiles return the backend error "No entities matching criteria found" in ~40 ms.
- Observe the UI.
Observed
- Backend: immediate, explicit fast-fail (
No entities matching criteria found) on both endpoints, ~40 ms.
- Frontend: indefinite "Config generating…" progress indicator; polling continues; a
Load error 500 appears but the failure is never presented to the user. The state is indistinguishable from a long-running generation (we observed 70+ minutes of apparent "freeze" before diagnosing it).
Expected
The backend's fast-fail should be propagated to the UI as a terminal error state: stop the progress indicator, show the actual message ("No entities matching criteria found"), and suggest the likely cause (seed/ontology mismatch, empty extraction).
Suggested fix
- In the polling/progress component, treat a non-2xx response from
/prepare and /generate-profiles as terminal: stop polling, render the backend error body.
- Distinguish "still generating" from "failed" in whatever status endpoint the poller reads, so a 500 can't be swallowed as "pending".
- Optionally, backend: return a structured error code (e.g.
NO_ENTITIES) so the frontend can show a targeted hint.
Context / disclosure: We are an independent research team auditing multi-agent simulation pipelines. We found this while running a systematic 18-run study on MiroFish-Offline across four LLM families. We plan to publish a reproducible study referencing this issue in roughly 4 weeks, and we're happy to share drafts with maintainers beforehand. Thank you for open-sourcing this project — it made this kind of research possible in the first place.
Summary
When the seed document yields zero entities matching the generated ontology, the backend fails fast (~40 ms) with an explicit error — but the frontend never surfaces it. The UI stays in a perpetual "Config generating…" progress state (with an unrelated-looking
Load error 500in the console), which reads as a hang. In an earlier run we waited 70+ minutes on what we then believed was a backend deadlock; source-level and network-level re-testing showed it was a UI-layer artifact over a clean, immediate backend failure.Reproduction
/prepareand/generate-profilesreturn the backend error"No entities matching criteria found"in ~40 ms.Observed
No entities matching criteria found) on both endpoints, ~40 ms.Load error 500appears but the failure is never presented to the user. The state is indistinguishable from a long-running generation (we observed 70+ minutes of apparent "freeze" before diagnosing it).Expected
The backend's fast-fail should be propagated to the UI as a terminal error state: stop the progress indicator, show the actual message ("No entities matching criteria found"), and suggest the likely cause (seed/ontology mismatch, empty extraction).
Suggested fix
/prepareand/generate-profilesas terminal: stop polling, render the backend error body.NO_ENTITIES) so the frontend can show a targeted hint.Context / disclosure: We are an independent research team auditing multi-agent simulation pipelines. We found this while running a systematic 18-run study on MiroFish-Offline across four LLM families. We plan to publish a reproducible study referencing this issue in roughly 4 weeks, and we're happy to share drafts with maintainers beforehand. Thank you for open-sourcing this project — it made this kind of research possible in the first place.