First round creation without images succeeds with zero entries, blocking subsequent round creation

[ayushshukla1807]

If you try to create a new round from the UI but forget to fill out the thresholds or drop a broken CSV link, the frontend fires it off to the API anyway.

The backend obviously crashes with a KeyError or ValueError which forces a 500 error back to the client. We really just need to tighten up RoundNew.vue to trap these edge cases before the network request is initiated.

[Sanika123-art]

Hi,
I am sanika palav,I tried to fixed this issue because yet i have come this 500 status code issue.Fixed the 500 error during round creation by adding proper validation and error handling. Invalid or missing inputs no longer crash the backend and now return user-friendly warnings instead.

[ayushshukla1807]

Thanks for the contribution @Sanika123-art!

Just to give some context on the architectural differences between our approaches:

PR #454 (my fix) intercepts the invalid payload before it leaves the browser — the validation guard runs synchronously in the Vue component, so the malformed request never reaches the network layer at all. No API call is made, no server resources are consumed, and the user gets instant feedback via alertService.error().

PR #476 wraps the backend import logic in a try-except block, which handles the crash after the bad data reaches the server. This is a valid defense-in-depth layer, but it doesn't eliminate the 500 error for organizers who have already triggered it — it just surfaces a warning instead of a stack trace.

Ideally both layers should exist (frontend guards + backend error handling), but they address different parts of the problem. Happy to coordinate if it helps the reviewers evaluate them cleanly!

[Sanika123-art]

Thanks for the detailed explanation!

That makes sense — your approach prevents the issue at the source by validating on the frontend, while mine focuses on handling it safely on the backend once it reaches the server.

I agree that having both layers (frontend validation + backend safeguards) would make the system more robust overall. Happy to align the approaches or update my PR if needed to better complement yours.

Let me know what you’d prefer from a review/merge perspective!

[lgelauff]

The original 500 is no longer reproducible. The backend now handles empty/missing category input gracefully — the import call returns a warning (no entries imported) rather than crashing, which is a welcome improvement. The crash-fix framing in the issue title is outdated.

However, the underlying UX problem is still present:

Current behavior (tested on master, 2026-04-14):

1. Organizer submits a new round with an empty import source
2. addRound succeeds → round is created and immediately set to active
3. importCategory fires → backend imports 0 entries, returns a warning
4. Frontend shows a popup: "Import Warning / no entries imported"
5. Round now exists, is active, and is empty

The organizer then tries to fix this by creating a new round. They get:

Bad request: can only create one active round at a time

They are stuck. To recover they need to manually cancel the empty round before trying again — which is not obvious in the UI and shouldn't be required.

Root cause:

The flow is two separate API calls that are not atomic. addRound commits before importCategory runs, so a failed import leaves behind a valid but empty active round — which blocks further progress.

Desired behavior:

If the import produces zero entries, round creation should fail entirely — no round is created, no active-round slot is consumed, the organizer gets a clear error and can try again immediately.

What's needed:

Both of the following are required:

(A) Frontend validation (pre-flight): Before firing any API call, submitRound() should reject an empty import source with an inline error. This prevents the obvious case cheaply and gives instant feedback.

(B) Backend atomicity: The createRound + importEntries flow should be a single atomic operation (one endpoint, one DB session). If the import returns zero entries, the session is rolled back and no round is persisted. This is the safety net that catches cases where A didn't fire — for example, a category that exists but is empty, a CSV with no valid entries, or any unexpected failure after round creation.

---

Re: PRs #454 and #476: Neither addresses the atomicity problem as described above. PR #476 improves error reporting on the backend but still leaves an empty active round in place. PR #454 covers the obvious empty-input case on the frontend but not a category that exists and is legitimately empty. Both would need to be extended to fully resolve this — happy to discuss before anyone picks this up.

[Sanika123-art]

Thanks for the detailed analysis — this clarifies the root problem really well.

I initially worked on fixing the 500 error by adding backend safeguards (try–except + graceful warnings), which ensured the API no longer crashes and the flow remains stable even with invalid input.

While testing further, I observed the same UX issue you described:

• A round gets created even when the import results in zero entries
• This leaves an active but empty round, which blocks further round creation
• Recovery is not intuitive (manual cancel + refresh required)

Additionally, I noticed a few related issues:

• Invalid or non-existent categories can still lead to empty round creation
• The delete/cancel round flow sometimes requires a manual refresh to reflect state changes

I agree with your breakdown that this requires both layers:
(A) Frontend pre-validation to prevent obvious invalid submissions
(B) Backend atomicity to ensure createRound + import behaves as a single transaction

My current fix (PR #476) improves backend stability but does not yet address atomicity.
I’d be happy to extend this further by:

• Preventing round persistence if imported entries = 0 (transaction rollback)
• Or exploring a combined endpoint approach for atomic round creation

Let me know if you'd prefer this to be handled as:

1. An extension to the current PR
2. A separate PR focused on atomic round creation

Happy to align with the project direction

[Sanika123-art]

Hi @ayushshukla1807 and @lgelauff

I am a bit unsure about the correct expected behavior here, so please guide me.

After latest changes:

• round is cancelled when entries = 0
• but frontend still sometimes shows "Round created successfully"

Should this be handled as:

• frontend bug fix (update success condition), or
• backend response contract change, or
• should we treat 0 entries as success with warning?

Please guide me on the correct approach so I can align my changes properly