Intel Map Regularly Broken

124»

Comments

  • I'm seeing the same thing - portals missing initially, but there on the 5minute refresh. I'm (re)loading a small area that only has around 200 portals. So any rate limit can't be relevant.

    It is almost as if the response to the client is being generated when the first response from the servers (containing some of the portals and most of the links) is recieved. The additional responses fill up a cache, and haven't (usually) been flushed when the 5minute refresh is requested.

    Wait a few hours and a refresh only shows some of the portals.

  • ofer2ofer2 ✭✭✭✭✭
    edited January 2020

    @Perringaiden Yeah, its called the dashboard internally. Sorry for any confusion, I'll try and call it Intel to be clear. I dont know how long this process is taking you, but depending on timing the number could go up because enough time has expired from the last time you've requested to merit additional requests. That being said, it does seem like it isnt that but something else. If there are enough tiles which arent cached, it will return the cached ones and load the uncached ones in the background. This is because a request cant run for too long (as I've mentioned before). Intel has always been this way. There is a lot of nuance into when/how it does this, but has the amount this happens changed since the revert or is it just as bad?

    @beardedtit Same question for you: does it happen just as much after the revert as before?

  • Jo0LzJo0Lz ✭✭✭✭✭

    Yesterday and this morning, I’ve had one request failed, that was visible. Didn’t notice any issues. Before that there were errors every time the map was loaded.

  • edited January 2020

    @ofer2 The 'classical' way that it's skipped out tiles however, is that in the tile response you'll get:

    {"result":
        {"map":
            {15_5459_12761_0_8_100: {gameEntities: [all the tile data]} }
            {15_5460_12761_0_8_100: {error: "TIMEOUT"} }
        }
    }
    

    from the getEntities call.

    We are seeing the TIMEOUT errors, when a given tile is not loaded in the cache, but we're also seeing tiles returned successfully, that do not contain all of the data for the tile. It's the second case that seems to be the problem, almost as if some of the tile loaded, and the cache decided that was enough and it was good to return instead of sending a TIMEOUT for the client to re-request it.

  • Of note, this is not to do with 502 errors or {} blank responses at all. Those have all but gone away, although we still occasionally get 502 errors, but IITC is smart enough to retry those.

    But rather the original issue starting November 26th (AFAIK) is that the system is acting as if it successfully loaded a tile, and returned some of the data for that tile, but not everything. On a refresh (or sometimes two or three), it usually gets all of the data.

  • jontebulajontebula ✭✭✭✭✭

    Not loading all portals! Please fix it soon. @NianticBrian

  • I think it would be helpful to note what Ingress Intel itself is doing rather than just IITC. IITC is a third party application and Ingress's primary concern is whether or not the official application is functioning correctly. Granted IITC can give you some indicators of what's going on that you might not see in Intel but Intel gives indicators as well that don't present on IITC albeit less transparently.

  • edited January 2020

    IITC replicates all of the Intel calls. The major difference in this area, is that IITC will retry 502 and blank response calls, where Stock does not appear to.

    Both will successfully re-request any responses containing TIMEOUT.

    The issue is not something IITC is doing, or something Stock is doing, but rather, something to do with what the getEntities call is returning.

    It's also far harder to use Stock to diagnose these issues, because of the lack of transparent code.

  • I can't use 'stock' it is just impossible to get it panned and zoomed from (0,0) to my current locstion.

  • It's super slow, but if you wait for it to load, you can usually move it after that point. Rembering too that it's trigger for loading data is the instant move, so you can't pan in sets, you have to let it load a bit each movement. (Frustrating yes, and easily fixed with a longer delay after moving.)

  • beardedtitbeardedtit ✭✭✭
    edited January 2020

    It all isn't helped by android detecting the move/zoom gestures accurately, nor taking ages to complete the load.

    Of course, I could go upstairs and use of of the desktops.

    But that doesn't help when doing 'on the hoof' field planning - where a 10" tablet is excellect.

  • edited January 2020

    That's where IITC-CE Mobile is worthwhile too.

    Honestly, I couldn't care less about the actual Stock UI and the client side processing. Niantic would be far better served by making a publicly accessible API that different people can develop UI's for. Niantic has shown that they don't care terribly for the Intel map itself, since it hasn't had a significant change or performance increase since they removed the full portal data on load back in 2013(?). A minor addition of being able to represent planned links doesn't make it a tool people will use.

    We want the data, to represent and manipulate ourselves. Just give us an API and put all your focus on making sure that the data is correct, complete, and rapidly served.

  • ofer2ofer2 ✭✭✭✭✭

    @Perringaiden I think I might have an idea. Hopefully I can get it out for you to test tomorrow. (But also, just as an FYI, even if it returns a set of portals, those werent ever guaranteed to be completely accurate, only most likely to be). Hopefully you can let me know if I've fixed / improved it tomorrow.

  • Until 30th November (or thereabouts) I don't think anyone had ever noticed a missing portal, after that date nearly every load had significant numbers of missing portals and the occaisional missing link.

  • edited January 2020

    But also, just as an FYI, even if it returns a set of portals, those werent ever guaranteed to be completely accurate, only most likely to be

    We've always accepted that the state of a given portal may be slightly out of date given replication and refresh times. However, in terms of the 'physics' of the Intel map, we've never had a situation where portals aren't at least represented.

    I think that's the big thing that everyone's most up in arms about. Portal's state's change constantly and especially at times like Anomalies, Operators/Dispatch are basically refreshing and hoping for the best in a lot of cases. But not being able to even see a point for a given portal is far worse. It's almost like looking at Google Maps and having map tiles simply missing. When all the tiles are present, we might not know the traffic situation, but at least we can see the road.

    Simply failing to return that a portal exists is essentially the "unforgivable sin".

  • edited January 2020

    @ofer2 I did my large reference test. I'm posting here because it requires IITC, and can't be done natively on stock so I didn't want to muddy the waters on the reporting thread.

    • Result: 40120 portals out of 43k+
    • 502 Errors: None
    • Prematurely closed sockets: None

    It's far better than the usual 'first load' of the day, though still missing about 3k of portals (not sure of an exact number since I've never been able to load all of them since the end of November).

    I'll see if I can find some specific examples using Stock for the other thread.

  • ofer2ofer2 ✭✭✭✭✭

    @Perringaiden thanks for your help on this! Sorry I didnt mention this earlier, but for that specific bug, you need to look at a new area as cached portals will still be there.

  • What's the approximate time I should allow before I can run that again with an expectation that caching would have expired? I'm going to run it on some other cities twice to see the difference, but LA is the best area I know for scale.

  • ofer2ofer2 ✭✭✭✭✭

    As long as no other entity has interacted with the portal in 7 hours, it will fall out of the cache. This includes game servers as well.

  • Ok, I'll give that wide view another test late tonight.

  • @ofer2 if you're entertaining any requests for the Intel page, it would be really nice to have a way to request HISTORIC scores for the septicycles. If not the full history (which might be a bit much, but it'd be nice) then certainly to display the final score (who won/lost) from the previous cycle.

    Currently, when checkpoint 35 hits, the scores go immediately to show 0-0, rather than showing the final result of the septicycle. On a close cycle, you might not even know who won...


    Anyway, just sharing a wish list. Definitely think first order of business is getting the map to show an accurate game state. And thank you.

  • Jo0LzJo0Lz ✭✭✭✭✭

    you could just go into the scanner and click on history in the bottom left...

  • That works for the cells around you only, and has a cooldown after a certain number of requests.

  • Wait is that why we were getting cooldown messages any time you even looked at score?

  • On the Intel map, no. That was the only error text available when the request 502'd out.

  • jontebulajontebula ✭✭✭✭✭

    @NianticBrian Cant see all portals now on Intel! 😪

  • drh4kordrh4kor ✭✭
    edited March 2020

    It's 'borked' yet again, at least on Chrome Version 80.0.3987.132 (Official Build) (64-bit). Cleared cache, still no joy.



    Firefox working as advertised, tho on version 68.5.0esr (64-bit)

Sign In or Register to comment.