Prevent duplicate chapter-generation workers per session

[Copilot]

/generate_chapters had no guard against launching multiple background workers for the same session — repeated clicks or multiple tabs could spawn competing threads writing to the same session state.

Backend — session-scoped guard (novelforge/routes/generation.py)

Before spawning a worker, the route now checks whether session["progress_token"] already points to a "running" entry in _progress_store. If so, it returns HTTP 409 with the existing token:

{
  "error": "A chapter generation is already in progress for this session.",
  "error_code": "generation_in_progress",
  "token": "<existing-token>"
}

Frontend — button lifecycle (static/js/script.js)

• btn-approve-outline is disabled on first click and stays disabled for the full duration of generation. Removed the blanket re-enable from the approve_outline complete handler.
• Re-enabled only on: approve_outline failure, generate_chapters non-409 failure, generation done (showDoneStep), or generation error (poll error branch).
• 409 is handled gracefully: client silently attaches to the existing token and begins polling — no user-visible error.

Tests (tests/test_concurrency.py)

Replaced test_two_generation_requests_get_different_tokens (which incorrectly expected both requests to succeed) with four targeted tests:

Test	Behaviour
test_first_generation_request_succeeds	200 + token stored as running
test_duplicate_generation_request_blocked_with_409	409 + existing token returned, single store entry
test_new_generation_allowed_after_previous_completes	200 once prior token is done
test_rapid_repeat_calls_all_blocked_after_first	5 calls → [200, 409, 409, 409, 409]

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• api.openai.com
  • Triggering command: /usr/bin/python python -m pytest tests/ -v (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[Copilot]

Pull request overview

Prevents multiple /generate_chapters background workers from being launched for the same user session (e.g., repeated clicks / multiple tabs), and updates the UI + tests to support the new behavior.

Changes:

• Added a session-scoped guard in /generate_chapters to return HTTP 409 with the existing progress token when generation is already running.
• Updated frontend button enable/disable lifecycle to avoid re-enabling “Approve & Write Chapters” while generation is in progress, and to attach to an existing token on 409.
• Reworked concurrency tests to validate first-call success, duplicate-call 409 behavior, and “new run allowed after done”.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
novelforge/routes/generation.py	Adds a guard intended to prevent starting duplicate generation workers per session.
static/js/script.js	Keeps the approve button disabled during generation; handles 409 by attaching to the existing token and polling.
tests/test_concurrency.py	Replaces prior token-expectations test with targeted tests for 200/409 behavior and post-completion regeneration.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The duplicate-worker guard relies on reading session["progress_token"], which is only updated at the end of the request. Two truly concurrent /generate_chapters requests from the same session can both observe no progress_token (or a stale one) and each start a new worker, so this doesn’t fully prevent duplicates under real concurrency.

Consider making the check-and-reserve atomic using a server-side key (e.g., session_id = get_session_id()), protected by _progress_lock: maintain a session_id -> active_token mapping (or store session_id in each progress record and look it up) and set it before spawning the thread. Also keep the status check within the same lock to avoid TOCTOU edge cases where status flips between read and decision.