Operator-stats endpoints (`fullStats` and `operatorStats`) returning stale data for 2+ hours despite confirmed active ranked play

DeplorableTM

0 views 0 replies

More on the stale stats bug I have been seeing. I'm seeing a reproducible staleness issue specifically with the operator-level stats endpoints (type=fullStats and type=operatorStats), while the ranked-stats endpoint (type=stats) updates correctly and promptly on the same accounts in the same time window. This rules out a game-mode or account-specific explanation — I confirmed all activity during this test was ranked play.

Evidence — Account 1 (DEPLORABLETM, platform: uplay/pc):

Three timestamped captures over ~2 hours, querying all three endpoint types simultaneously:

Time type=stats kills/deaths/wins/losses fullStats & operatorStats total kills/deaths/matchesPlayed
16:12:25 495 / 508 / 59 / 55 13,403 / 12,272 / 11,754
17:30:44 505 / 517 / 60 / 56 13,403 / 12,272 / 11,754 (unchanged)
18:07:56 514 / 522 / 60 / 57 13,403 / 12,272 / 11,754 (unchanged)
Rank/RP also moved correctly over this window (18 / 2700 → 17 / 2675), confirming real ranked matches were completed. The type=stats numbers track this activity accurately and promptly. The operator-stats numbers (identical between fullStats and operatorStats — ruling out an endpoint-specific bug) did not change at all across the full 2-hour span, despite multiple confirmed matches.

Evidence — Account 2 (a second, unrelated account on the same Discord server), same poll cycle:

Our application logged a simultaneous poll showing the identical pattern:

Ranked wins/losses: 31/38 → 31/39 (a loss registered correctly)
Operator-stats kills/deaths: 2559/3030 → 2559/3030 (completely unchanged)
Two independent accounts, same time window, same symptom — this doesn't appear to be isolated to one account.

Summary:

type=stats (ranked profile): refreshes correctly and promptly
type=fullStats and type=operatorStats: return byte-identical, stale data for 2+ hours despite confirmed new ranked matches on multiple accounts
Can you confirm whether there's a known caching or aggregation delay specific to the operator-stats endpoints, and if so, what the expected refresh interval should be? Happy to provide the full raw JSON captures if useful — I have all three requests' full responses saved with timestamps.

Thanks for looking into this

Replies

R6Data

Thank you very much for bringing this to our attention. We are currently looking into the issue, although we believe it may be down to the way Ubisoft updates its server-side data, so we are trying to find a way to resolve this problem. We’ll keep you updated.

DeplorableTM

Thanks for looking into this. It didn't happen before introducing caching times though. Unless Ubi changed something since then.

R6Data

We are experiencing a delay in Ubisoft updating the data; we are looking into how to resolve this.

DeplorableTM

any updates?

R6Data

At the moment still nothing

DeplorableTM

thats too bad. its weird the win loss data comes in quickly but not the rest. is there another endpoint that I should be using?

R6Data

We’ve most likely managed to sort out the issue, please let us know if it’s been resolved.

DeplorableTM

It looks like its back to getting updated hourly. In testing I did find a lot of interesting things that are at least new/a realization for me.

in the JSON file there is a board_id Ranked, that seems to update rather quickly with W/L and overall K/D etc...

Then you have the operators section - where you get alot of the fun data like K/D by operator, aces, clutsches and all of that. That is the part that was lagging and now seems to be updated in that hour time frame.

am i reading that all correctly?

R6Data

Yes, you stated everything correctly. The issue has been resolved.

DeplorableTM

thank you. I appreciate the help and support.

R6Data

We are happy to be able to help our users, thanks to you

Operator-stats endpoints (`fullStats` and `operatorStats`) returning stale data for 2+ hours despite confirmed active ranked play

Replies

Your Reply