A community member implemented passing a custom Helicone-Request-Id (a uuidv4) to the header to enable thumbs up and thumbs down feedback. However, they noticed that some responses were missing, even though the code worked for one API route. When they rolled back the changes, the missing responses started appearing again. The community member is seeking ideas to resolve this issue, as the thumbs up and down feedback would be valuable data for fine-tuning.
In the comments, another community member suggests ensuring that the Helicone-Request-Id is generating a new uuid for each async request, as passing the same uuid for all requests could cause conflicts on insert.
There is no explicitly marked answer in the provided information.
I implemented this afternoon of passing Helicone-Request-Id with a custom uuidv4 to the header to implement a thumbs up and thumbs down feedback. However, amongst implementing it, I realise responses are missing despite checking that the code works for the one API route I have (i.e it logs the response some times but misses it sometimes with the same route).
I then rolled back to previous version without the Helicone-Request-Id and the response about seems to start rolling back up.
During the time when in production I implemented setting the custom Helicone ID, I have searched for some certain responses I did myself which were missing too.
Any ideas for this? Having the user thumbs up thumbs down feedback will be nice data for us to have for finetuning.
Hi! Thanks for reporting this bug - I am sorry for the inconvenience. The team and I will look at this ASAP. Do you have an email we can send updates to?
When you are generating the Helicone-Request-Id uuid in code, is it generating a new one for each async request you are sending. Potentially you are passing in the same uuid for all async requests which is causing conflicts on insert
