Only huggingface client works, and crashes server about turbopilot

[ravenscroftj]

Thanks for raising this. I'm not having any issues with the fauxpilot plugin so that's really interesting sorry to hear that it's not working for you. I might have a dig around and see if I can recreate that issue. Are you on Mac OS?

I haven't had a look at the co-pilot official plugin for a while - it seems particularly annoying/tricky to reverse engineer and I've not had time to figure it out

The HF issue is interesting. You're right that the problem is caused by multiple requests being serviced by the same device. I'm not entirely sure that cancelling previous requests would be the desired behaviour (what does the hf plugin do with those requests? Are they actually invalid or is it trying to gather multiple results? What about a use case where multiple users want to make requests from the same server?). However, queueing requests or using some sort of locking/mutex structure might provide a short term fix.

[aperullo]

Thanks for the reply! No I am actually running all of this on fedora.

The HF plugin doesn't seem to care, it shows only the results from the latest request. I can't verify for sure but if the server isn't available (ie still starting) it'll just happily wait forever. The first request that is sent and responded to satisfies it and it stops listening to other requests is how it appears.

In retrospect that makes sense, I'm almost certain official one is built to discard all requests except the latest, because the inference isn't fast enough to keep up with someone typing without pause.

That's why I figure some kind of ID per user would be better, though if the plugin doesn't send something like that already I can see how it would be tough.

A queue doesn't sound right, you'd want to serve the latest request from each user no?

If a request is sent for

def divideby

the completion should be

def divideby(x,y):
    return x/y

But if I kept typing while turbopilot was crunching away and now my code says

def divideby2(x):

Then the completion turbopilot is already working on isn't useful to me anymore.

However having a lock is absolutely better than having the server crash.

[ravenscroftj]

The locking change has gone in. I agree that it would probably be nice to have a way to cancel ongoing requests - I need to better study the crowcpp docs and see how I could go about doing that.

My thinking is to have the model evaluation loop try to acquire a semaphor and break after evaluation of each token. Then, have Crow throw up the semaphor if a connection is closed prematurely. I need to see where this logic could hook into.