Add "Retry" button

[koppor]

Known from OpenAI UI. When something goes wrong, there is a "Retry" button.

JabRef currently just leaves one with the error message (here: Misal AI is used)

I would like to simply retry the message.

[InAnYan]

I just don't really understand how the UI should work in these places.

What do you think about this approach:

When AI provider sends error, then:

1. Text field and submit button are replaced with two buttons: "Retry" or "Cancel"
2. On clicking "Retry", the error message disappears, UI changes to "waiting mode", and then we either get another error (go to step 1) or response from AI (restore text field and "submit")
3. On clicking "Cancel" error message and last user message are gone, and message text field with "submit" button are restored

[koppor]

Sounds great!

[InAnYan]

From Thi Lo: add a general retry button, to 1) regenerate response, 2) retry for error

[InAnYan]

I CAN'T BELIEVE it was so easy to make this feature.

Something, should be wrong...

So, it needs testing

[koppor]

I did not think through completely. Sorry.

"Cancel" should just cancel the retry. An activity "cancel" should not delete something.

JabRef should just return to the chat itself and have the system message there

---

Future work: Delete icons next to each message to delete a message

[ThiloteE]

Regenerate button did work.

Though, can we have a regenerate button for AI chat too? Would love to have that.

[ThiloteE]

I think any potential "Cancel" button should cancel the generation, regardless if triggered by "regenerate" or "submit".

[InAnYan]

#118 (comment) Hmm, I see.

But then in the UI it will appear like this:

• User: "sending message with error"
• JabRef: "Error: ...."
• User: "continue message"
• JabRef: "Not error".

But in the chat history that would be stored like this:

• User: "sending message with error"
• User: "continue message"
• JabRef: "Not error".

So, error message is disappeared, and there are 2 user messages in a row.

What should we do:

1. "Cancel" will remain all messages, thus the situation I described will be like that
2. "Cancel" will delete messages, like in current implementation --> leads to consistency (User-AI, AI-User, User-AI, etc.)
3. Store errors in chat history

[ThiloteE]

But then in the UI it will appear like this:

* User: "sending message with error"

* JabRef: "Error: ...."

* User: "continue message"

* JabRef: "Not error".

But in the chat history that would be stored like this: But then in the UI it will appear like this:

* User: "sending message with error"

* User: "continue message"

* JabRef: "Not error".

Ruslan, can you edit your message? It looks like you forgot to delete some parts or wanted to add some parts. In particular how the chat history would be stored. I think this is vital information about how to deal with this issue.

Depending on the info about how chat history is stored, my opinion might change, but currently, out of your options, I favor a combination of 1. and 3. IF we have delete icons next to each message to delete a message. Until we have delete icons, I am in favor of 2. for the time being.

[InAnYan]

Oh, sorry, I've just copy-pasted the text.

I hope you understood what I meant

[InAnYan]

Okay, after thinking, I think if user message question is gone, it's not cool. What if they want to reask it? Maybe they got wrong API key, and then they return back...

[ThiloteE]

Users DO want the user message to be gone, if they want to have a different response.

Remember the "temperature" option in the preferences? That will allow you to have a different response each time you press the "retry" button (at least up to a certain degree. Of course, after a few dozens or hundred times of pressing the button, the responses will feel very similar, depending on your temperature settings)

[ThiloteE]

Almost every AI GUI hast this button and they delete the last message upon retry. JabRef would be the outlier here.

[InAnYan]

Okay then, I understood.

I implement "Delete" button and do options 1 & 3

[InAnYan]

But then, what should we do after clicking "Cancel"?

Should we delete the user message too?

But then, we won't need 1 & 3

[ThiloteE]

No. "Cancel" is a different feature. It is like a "Pause" or a "Break". Let's say the model is very verbose and starts to respond with a 10 000 tokens long response and it just doesn't stop, then pressing the "Cancel" button will allow you to stop the generation. It will also allow you to stop the generation, if you believe there is an error.

In this case, "deleting" the message is not wanted, because you may want to see what the model responded with. You may want to see the error message. You may want to see the start of the model's response, because having seen 200 out of 10 000 tokens might already have been enough and then users might want to copy and paste that part of the generation, etc.

TL;DR: I favor: Press "cancel" --> Stops generation, but does not delete the message.

[InAnYan]

@ThiloteE, what should "Cancel" button do on error from AI?

[ThiloteE]

I am in favor of ""Retry" will delete messages --> leads to consistency (User-AI, AI-User, User-AI, etc.),if we can log the error messages somewhere else in JabRef and not in conversation, because I strongly believe disturbing users workflow with lots of errors and warnings is bad UI design (and it also looks ugly). But since it apparently only is possible to log the error messages in the conversations with langchain4j (at least that is what you said), deleting messages upon retry will lead to error messages getting lost, so that's not good either...

[ThiloteE]

@ThiloteE, what should "Cancel" button do on error from AI?

If there is an error message, then show the error message, unless we can log it somewhere else in JabRef. Please do not confuse "cancel" with "retry".

[InAnYan]

@ThiloteE, I mean this issue. Okay, let's start like this:

1. User sends message
2. AI provider sends "Error: ..."

What should be done in this case?

1. Should we just proceed?
2. Or new UI should be added?

[InAnYan]

Closing, as implemented both "Retry" and "Cancel" buttons (the behavior of "Cancel" button was discussed with Thi Lo in a call, it won't delete any messages and it will just switch to default state)