WvW matches down 2017-02-22
It’s actually totally unrelated; for the WvW APIs I basically broke everything. Thought the fix I put into the first hotfix would correct the issue, but there turned out to be a totally unrelated issue that caused it to still be broken.
I’ll have it fixed tomorrow provided the rest of the API backend doesn’t explode and catch fire.
Sorry
Awesome, thank you very much for the update – looking forward to seeing it up and running again.
Thank you very much for the information and honesty! I am sure a lot of people will be glad to know whats going on.
Okay, it’s back up now, but due to EVEN MORE BUGS (i did this) it’s only being held together with gum and duct tape. Some caveats while I work through the underlying problems:
- Linking data is currently hardcoded.
- Matchup data is currently hardcoded.
- The whole thing is liable to catch fire and burn down.
On Friday (and next Friday ;_;), I plan to disable the endpoint when the scores zero, then manually update the hardcoded bits once the new matchups are decided, then turn it back on; should be back up before the initial RI runs out.
Are all these problems related to an update of the api? I dont recognize seeing points_tick, points_capture, yaks_delivered or upgrades before. Also appears that there are objectives with a new “Spawn” type.
Any ETA when all the problems are going to be solved? If not an exact date, just a rough estimation. Will it take more than a week?
Are all these problems related to an update of the api?
Specifically, to an update to one of the API’s backend components. Long story short, we updated how WvW data is stored last year and the API component has been using the old data source which doesn’t have some of the newer features. Talking to the new data source is a bit involved so I’ve been rolling back after finding more bugs on stage each release. This time the bugs didn’t crop up until it was on live (whoops).
Despite that, this time everything appears to be working except for the merges/matchup worlds, which I can just update manually at reset until the next release. Everything should be more-or-less good to go after the next release (i.e. patch not hotfix).
I dont recognize seeing points_tick, points_capture, yaks_delivered or upgrades before. Also appears that there are objectives with a new “Spawn” type.
The updated backend code has support for the extra fields, so the API frontend detects that and just emits them with the response. There’s an open PR on github for those that needs to be closed out (I’ll have to go through github and merge a bunch of stuff I think). I can strip out the Spawn objectives if wanted; IIRC some application developers and I had a discussion on gitter and the conclusion was to just leave them in.
EDIT: Hmm I guess I should fix the v1 API as well.
(edited by Lawton Campbell.8517)
Wow, and now score is score of the current skirmish (and not the total score of the week). Is it a another bug or is it defenitive ?
Author of the MoS matchups Tools
http://mos.millenium.org/matchups
Wow, and now score is score of the current skirmish (and not the total score of the week). Is it a another bug or is it defenitive ?
Uhh, that’s a bug.
Sorry, bear with me on these changes.
EDIT: also apologies for this disaster; I’ll bundle the fix for that one with the /v1 deploy later today.
(edited by Lawton Campbell.8517)
Seems to be working again, but now kills and deaths are equals to 0
Author of the MoS matchups Tools
http://mos.millenium.org/matchups
Seems to be working again, but now kills and deaths are equals to 0
After briefly panicking, the fix for the KDR data is en-route.
Hopefully this will be the last stop on today’s pain train.
Q_Q This is not a good set of links.
Q_Q This is not a good set of links.
Hey man I don’t make the rules I just break the API endpoints.
I updated the temporary hardcoded API configs for the NA merges+matchups; let me know if I botched something else; I’ll check back later tonight. AFAIK everything should be working (KDRs should be fixed, /v1 endpoints should be fixed, scores should be the total match scores, not just skirmish scores, etc).
What a week.
I think there is another issue with global score.
The global score seems to roll back at each new skirmish and becomes smaller than a few minutes before.
Here is an example : http://mos.millenium.org/servers/view/8/ and we can see at each beginning of a skirmish the same value for several minutes.
I save every 15 minutes the global score. If the score is fewer than the previous score (it should not be possible) i save the same value as the previous score (that’s why the graph show same value for several minutes after a new skirmish).
Currently, for Piken Squre, my last saved score was 109,568 (at 5 PM CEST). At 5:44pm CEST, the api return 109,113 for piken square.
NB. I’ve just updated the tracker, and now it will save the exact value returned from the api even if the current value is fewer than the previous saved value.
Author of the MoS matchups Tools
http://mos.millenium.org/matchups
(edited by Weris.5248)
Ugh, best guess is that it’s including the current skirmish score twice. I’ll see if I can get that fixed next week; I’m all hopped up on cold meds right now and don’t trust myself to make any correct changes right now.
Next week I’ll look into exposing the raw skirmish data in addition to fixing this.
Okay, pushed some changes today that should fix
- /v2/wvw/matches was erroneously being cached for 5 minutes; it’s now back to a 1-second cache (hooray for complicated cache code).
- /v2/wvw/matches.scores (and .map.scores) no longer count the current skirmish twice. The scores should properly represent the total scores.
- /v2/wvw/matches.map.objectives.last_flipped should be properly “null” when it’s never been flipped (rather than 2001-01-01).
As always, let me know when you find further issues