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

[P1] Prevent silent loss of edits made during a new generation

Closed Beginner friendly
  • Is something wrong?
#2 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
74/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
javascript, python
Domain
frontend, testing

Research direction

Start with patchpitch/static/app.js, especially setBusy, render, the replacement confirmation, and the editing handlers; then review tests/test_browser.py for the existing edited-draft confirmation test. Add a browser regression that delays the second response while editing, and check that edits are not silently lost, the previous Markdown survives a failed request, and editing controls recover. Done when the existing confirmation still works and the new regression passes.

Written by the indexing model from the issue text.

Description

Finding

Reviewed commit: 0549e5b1e6d88aaa46a0e580dcaad5b177446997.

The output editor remains usable while a second draft is generating. When that response arrives, it silently replaces any edits made during the wait.

Reproduction

  1. Generate a first draft.
  2. Start a second generation and delay its /api/pitch response.
  3. While waiting, click Edit draft and change the existing Markdown.
  4. Complete the second response.
  5. The new manual text disappears, the editor is hidden, and no replacement confirmation is shown.

Confirmed by executing the unchanged app.js in a minimal Node DOM/fetch harness. This is a MOCK UI-state reproduction, not a live Gemma or Chromium run.

Code evidence

  • setBusy disables inputs inside #pitch-form; the result editor and Edit button are outside that form.
  • Replacement confirmation happens before the request, so it cannot protect later edits.
  • render unconditionally replaces currentMarkdown, resets edited, and hides the editor.
  • Editing handlers do not check busy.

Requested change and acceptance

The smallest fix is to disable both Edit draft and the editor during generation and restore them in the existing cleanup path. Preserving competing edits explicitly is also acceptable.

  • No text entered after a generation starts can be silently discarded.
  • Existing confirmation before replacing an already edited draft still works.
  • A failed or timed-out second generation preserves the previous Markdown and restores editing controls.
  • Add one browser regression with a delayed second response covering this sequence.
  • Link the fix commit and successful CI.

The current browser test checks canceling replacement of an already edited draft; it does not exercise editing while a request is pending.

Priority: fix before recording the final human-review/edit/export workflow.

Dominant language
Python
Stars
1
Forks
0
Avg merge
18m
Merged PRs (30d)
2

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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 drevendev/PatchPitch

All issues in drevendev/PatchPitch

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.