Closed romartin closed 3 months ago
@romartin With #1129, we changed the code not to send feedback if the completion API returns a non-200 status. May I understand you are changing that with this PR?
Good catch @TamiTakamiya ,
This implementation is not really caring about the completion response error codes, it just ensuring that if some completion event was send, and some other key change happens, which "ignores" the completion request, it send the corresponding feedback event. So maybe this brokes https://github.com/ansible/vscode-ansible/pull/1129, not sure, let me double check how it works with the non-200 repsonse error codes....
Will let you know something ASAP! Thanks!
Hey @TamiTakamiya , you were right, I fixed one issue but introduced another, once the response is not an HTTP 200. I am looking for a proper fix, and trying not to break anything else, anyway hope tests will help.
BTW Anything else I should take into account during this fix? (A part from checking response codes for sending feedback)
Thanks for the pointers!
Closing. No loner applies. Working on a new PR. Sorry for any inconveniences.
Hey @robinbobbitt @TamiTakamiya
See https://issues.redhat.com/browse/AAP-24192
Goal
The goal is to guarantee the correlation between
completion
/Recommendation Generated
events, along with theinlineSuggestionFeeadback
/Recommendation Action
ones, from the VSCode (client) perspective. It means this fix applies to bothschema1
andschema2
(although "seated" users actually don't send schema1 feedback events ...)Steps to reproduce
The actual vscode plugin behavior works as: 1- User writes a prompt and press Enter, so a completion request starts 2- Meanwhile the completion request is in progress (so suggestion not yet displayed to the user), if f.i. a WHITESPACE key is pressed, it does not send any feedback event. But completion event has been already sent. 3- But once pressing the BACKSPACE key (before completion req. above is in progress), the cursor is back to the original position, and another completion request is started, so another completion event is sent, which may end with some suggestion displayed, and the user accepting/rejecting/igrnoing the suggestion (feedback event) 4- Instead of step 3, the user, while the completion request above is in progress, can also press another key again, so the iteration starts again
Solution
Assuming once a completion is in progress, and the user press some other key that may cause completion to abort, at least send a IGNORED feedback event for each. This solution may result in an increase of the number of feedback events, but at least guarantees that once a copmletion req. (so event as well) is in progress, it send an IGNORED event once the user does something that "cancels" current completion
I understand I am changing the actual "desired" behavior , as some tests where not expecting that, so feel free to let me know your concerns or feedback please, or if I miss something. :)
Thanks!