If I close the magit window before GPT commit finishes generating a result, magit-gptcommit breaks hard

[rogsme]

Steps to reproduce:

• Open magit and add something to the commit.
• When GPT commit changes to "Waiting" or "Typing", quickly close the magit window.
• Reopen magit.
• Magit and GPT commit breaks and there's no way to recover other than a systemctl --user restart emacs.service.

If I manually run a magit-gptcommit-generate, I get "Selecting deleted buffer" in the message buffer.

[douo]

It looks like a bug in magit-gptcommit. You can first try running magit-gptcommit-abort to see if it resolves the issue.

[rogsme]

It looks like a bug in magit-gptcommit. You can first try running magit-gptcommit-abort to see if it resolves the issue.

Hey douo! First of all, thank you for this package! You and magit-gptcommit inspired me in creating ForgeLLM. I would really appreciate it if you could check it out!

Regarding this issue, that was the first thing I tried, but it didn't work. I might have some time today to look deep into the code and try pushing a PR, if that works for you 😁

[LemonBreezes]

Try #18 to see if that fixes the issue for you.

[rogsme]

Try #18 to see if that fixes the issue for you.

I'll try it out later today. Thanks!

[douo]

Thank you for your work. I've been very busy lately and haven't had time to deal with it. Looking forward to your feedback.

[rogsme]

@LemonBreezes I can confirm #18 does not fix the issue 😞

[LemonBreezes]

@LemonBreezes I can confirm #18 does not fix the issue 😞

It removes the error but the commits messages still cannot be generated or no change at all?

[rogsme]

@LemonBreezes I can confirm #18 does not fix the issue 😞

It removes the error but the commits messages still cannot be generated or no change at all?

No change at all, I still get the same error and the same type of crash

[LemonBreezes]

@LemonBreezes I can confirm #18 does not fix the issue 😞

It removes the error but the commits messages still cannot be generated or no change at all?

No change at all, I still get the same error and the same type of crash

Can you get a backtrace? I suspect it's the same error still. You may have to use this if the error is being suppressed (happens if the error occurs in a post-command-hook for example):

;;; Power debugging

;; Use this with `vertico--exhibit' for example to debug completion tables.
;; Copied from here:
;; https://gist.github.com/jdtsmith/1fbcacfe677d74bbe510aec80ac0050c.

(defun cae-debug-reraise-error (func &rest args)
  "Call function FUNC with ARGS and re-raise any error which occurs.
Useful for debugging post-command hooks and filter functions, which
normally have their errors suppressed."
  (condition-case err
      (apply func args)
    ((debug error) (signal (car err) (cdr err)))))

;;;###autoload
(defun cae-debug-toggle-debugging-function-on-hidden-errors (func)
  "Toggle hidden error debugging for function FUNC."
  (interactive "aFunction: ")
  (cond
   ((advice-member-p #'cae-debug-reraise-error func)
    (advice-remove func #'cae-debug-reraise-error)
    (message "Debug on hidden errors disabled for %s" func))
   (t
    (advice-add func :around #'cae-debug-reraise-error)
    (message "Debug on hidden errors enabled for %s" func))))

[rogsme]

@LemonBreezes I can confirm #18 does not fix the issue 😞

It removes the error but the commits messages still cannot be generated or no change at all?

No change at all, I still get the same error and the same type of crash

Can you get a backtrace? I suspect it's the same error still. You may have to use this if the error is being suppressed (happens if the error occurs in a post-command-hook for example):

;;; Power debugging

;; Use this with `vertico--exhibit' for example to debug completion tables.
;; Copied from here:
;; https://gist.github.com/jdtsmith/1fbcacfe677d74bbe510aec80ac0050c.

(defun cae-debug-reraise-error (func &rest args)
"Call function FUNC with ARGS and re-raise any error which occurs.
Useful for debugging post-command hooks and filter functions, which
normally have their errors suppressed."
(condition-case err
(apply func args)
((debug error) (signal (car err) (cdr err)))))

;;;###autoload
(defun cae-debug-toggle-debugging-function-on-hidden-errors (func)
"Toggle hidden error debugging for function FUNC."
(interactive "aFunction: ")
(cond
((advice-member-p #'cae-debug-reraise-error func)
(advice-remove func #'cae-debug-reraise-error)
(message "Debug on hidden errors disabled for %s" func))
(t
(advice-add func :around #'cae-debug-reraise-error)
(message "Debug on hidden errors enabled for %s" func))))

The output is:

Error running timer ‘plz--respond’: (wrong-type-argument (or eieio-object cl-structure-object oclosure) nil)

And the magit buffer gets stuck like this:

(sorry for the blurry mess, but this is private work stuff)

If I then run magit-gptcommit-abort, I get this:

funcall-interactively: Selecting deleted buffer

And nothing works, until disable magit-gptcommit-mode and refresh magit

I'll fork the repo later today and try to fix it, but thank you for your help so far!

[rogsme]

It turns out I'm just dumb. I was loading your fix incorrectly @LemonBreezes!

I figured maybe a video is better.

Now, this is what happens with your branch:

error.mp4

To explain what is happening:

• First everything works as expected
• Then if I close the magit window while it's still generating, and reopen magit, the status will be broken
• If then I run magit-gptcommit-abort a huge error will appear in the message, but if I refresh magit, it will start working again (this wasn't happening before, it was just broken forever)

This looks like a good enough fix. A better fix would be to just abort magit-gptcommit if it's still generating before closing the magit window, but I don't really know if that's something that can be done. That will be my approach when I start testing!

And thank you for your help @LemonBreezes! Sorry for being dumb and not loading your plugin correctly 🙃

[LemonBreezes]

It turns out I'm just dumb. I was loading your fix incorrectly @LemonBreezes!

I figured maybe a video is better.

Now, this is what happens with your branch:
error.mp4

To explain what is happening:

* First everything works as expected

* Then if I close the magit window while it's still generating, and reopen magit, the status will be broken

* If then I run `magit-gptcommit-abort` a huge error will appear in the message, but if I refresh magit, it will start working again (this wasn't happening before, it was just broken forever)

This looks like a good enough fix. A better fix would be to just abort magit-gptcommit if it's still generating before closing the magit window, but I don't really know if that's something that can be done. That will be my approach when I start testing!

And thank you for your help @LemonBreezes! Sorry for being dumb and not loading your plugin correctly 🙃

What is happening is that Doom Emacs kills the Magit Status buffer when you type q whereas magit-gptcommit expects you to bury the buffer and never kill it. Its async workers save that buffer so when it's killed, the workers keep that stale reference. I have seen another similar issue here magit/forge#744 and Tarsius decided to offer outputing to the echo area instead as an easier workaround.

What my code change does makes the workers do nothing when they complete their work and discard that commit message. That is at least better than returning an error and breaking completely.

@hlissner not sure we will make any code change to Doom Emacs but I think Hlissner should at least see this recurring issue.

[rogsme]

Hey @douo, @LemonBreezes!

I created a quick PR that should fix the issue completely. You can check it out here: #21

And here's a video proving that the issue is now gone 😄

fixed.mp4