Hello !
I made this ticket to let you know about a bug on the new prediction api. It is in beta which I imagine is the best time to report a bug 
The date “ended_at” provided when the prediction is solved is not the correct one. It is equal to the date “started_at” and therefore is not used much ^^
Have a good day
Hi,
I just toyed with it and tried to reproduce your issue, but it looks to be working just fine for me:
Mind giving some more details/examples?
Yes, i log all the response
For EventSub “channel.prediction.end” i log this output
Step to reproduce :
Launch prediction.
Lock response.
Ending prediction with response.
I have replicated this on the channel.prediction.end EventSub topic
Please confirm that that is the topic you are seeing the issue on you didn’t specify in yoru OP
I confirm, i have say that in my second message, its the topic “channel.prediction.end”
Yeah just wanted to confirm, my brain isn’t firing on all cyclinders yet this morning
I can report other bug like this if you want.
In the topic “channel.prediction.lock”.
The “locks_at” is never the date on which the prediction was actually locked. It is automatically set to the initial scheduled lock date.
Reproduce :
Launch prediction for 2 minutes
Lock the prediction prematurely after some seconds or 1 minute if you want.
the locks_at in the lock event is the initial datetime + 2 minutes and not the real locks date
Not sure if thats intended or not. But will add it to the report.
You also have the timestamp of the event anyway to utilise instead
I can’t believe that such visible bugs went online without anyone noticing xD
Thats why it’s open beta! for people to find and report things like this
I didn’t spot these since i don’t utlise that data.
I only use the locks_at at “begin” myself. If it locks early (or locks) I don’t show the time anywhere in my current use case
In my implementation, I send the event data to a websocket which allows me to distribute the information in a live overlay. I overloaded the data as I wanted. I need to know the real lock date.
I use the lock date to calculate how long I leave the prediction displayed once locked (30 seconds).
Personally I leave it up till it ends/resolved
Otherwise I’d do it after it’s been relayed to the overlay.
But I can see why you’d do it from the lock time instead of overlay event receipt
(I send less data to the overlay, just the title/outcomes/current prediction values) I don’t send the dates themself
Yes because my overlay must be able to be displayed at any time during the life of the prediction. I therefore permanently store the last state of the prediction on my websocket, which distributes it to the overlay which is its client.
I have to store the lock date because it allows me to know, if I display my overlay in the middle of its life cycle, how long I let this step display
Coming back to this locks_date problem, I think this is actually not intended at all.
The “channel.prediction.lock” event returns a “locks_at” while “channel.prediction.end” returns a “locked_at”. Each time the information is wrong. None contains the real locking date but only the programmed one when the term has changed as if we wanted to talk about the past.
“locked_at” is really self-explanatory though.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.