GraphService.ts/GraphDataProvider.ts exceptions when caching data

Imagery, data, and integrations
1

I have been using the Mapillary-js 4.1.2 runtime in a web page to display a map and navigate through street level imagery for some time. I use the jsdelivr version.

I mostly use default viewer constructor options, with caching enabled but with the sequence UI disabled (default is enabled, not sure if this matters). The cover is disabled too.
Not sure if this is important but the problem can happen, eg., with SF downtown imagery.

In all cases when landing, caching is performed and the spatialedges event is eventually fired with status.cached = true. This seems logicial.

However, I currently observe two issues, which I am developing below.

  1. Very often, I get the following errors (many entries) in the Javascript console:

Origin: GraphService.ts:340
Test: Failed to cache tile data (SOME_ID). MapillaryError: Failed to fetch data
at GraphDataProvider.ts:282:22

The spatialedges event nevertheless does fire, with status.cached=true, and navigation arrows show up.

  1. Sometimes, navigation arrows do not show up at all, when they should. In rare instances, only one faint (low opacity) arrow shows up. Recreating the viewer from scratch using the same imageId does show all arrows, however just calling viewer.moveTo() using the same id does not cure the problem, which is very problematic.

In the Network pane of Edge, I see no errors at all, just 200 status codes. Everything seems ok. Some ‘images?…’ graph queries return 0-byte content, but still with a 200 status code. ‘images?….’ queries matching SOME_ID (as introduced above) seem to return valid content.

One thing I tried is to disable caching. This seems to solve the problem, but offers a less smooth navigation experience obviously.

Do you have any idea about could be wrong? I have a Maplibre map inset somewhere in my page that downloads coverage tiles when landing too, and this is working fine.

2

Thanks for reporting! I think maybe image density in the area (you mention SF downtown) could be the cause here. Can you share some image IDs where you’ve experienced this behaviour in the past?

3

Sure, this definitely happens around image id 802941794144066, typically upon landing. It does not always happen, though, just very frequently.
Also, disabling caching only seems to solve the issue (of arrows not showing up). I can’t be sure because I have not tested enough and the API does not let me determine if arrows are indeed fully “loaded” or not (beyond the spatialedges event which does not seem to be sufficient for this purpose).

4

Thanks! Looks like the API requests get very close to timeout (30 seconds) in the area around that image so I can imagine that there could be situations where the requests time out and that would be the cause of the errors you see. We’ll look into optimizing this API query for areas with high image density.

1 Like
5

Sounds good. It is true this area is very dense. I will just disable caching for now and see how it goes in the future. Thanks for your insight and quick replies.

6

Just as I was sending the message I did notice I also got the same warnings in the console and the same unexpected behavior (missing arrows) with caching disabled :-(.