"Frozen" location result in ESI

[Redrazor]

Bug

Player tracking “freezes” on a specific system and does not update on jump or even on new request.

This is ESI (not apps) since I have tested it directly against the API on /latest (https://esi.evetech.net) and can confirm my location is not the one that is outputted (matches 3rd party apps)

The frozen/wrong location remained for up to 15 jumps both in J-space and K-space

Location was updated correctly at Downtime further supporting the idea that this is an ESI issue.

Request

GET /latest/characters/{character_id}/location/?datasource=tranquility

Response

(The correct response format but wrong system_id)

Headers

 access-control-allow-credentials: true 
 access-control-allow-headers: Content-Type,Authorization,If-None-Match,X-User-Agent 
 access-control-allow-methods: GET,HEAD,OPTIONS 
 access-control-allow-origin: * 
 access-control-expose-headers: Content-Type,Warning,ETag,X-Pages,X-ESI-Error-Limit-Remain,X-ESI-Error-Limit-Reset 
 access-control-max-age: 600 
 allow: GET,HEAD,OPTIONS 
 cache-control: private 
 content-length: 50 
 content-type: application/json; charset=UTF-8 
 date: Thu, 05 Jul 2018 19:10:35 GMT 
 etag: "831cc8454f94c5a197490a200ea2b6c9e3380bf1a8f6c55b083b12c0" 
 expires: Thu, 05 Jul 2018 19:10:40 GMT 
 last-modified: Thu, 05 Jul 2018 19:10:35 GMT 
 status: 200 
 strict-transport-security: max-age=31536000 
 x-esi-error-limit-remain: 100 
 x-esi-error-limit-reset: 25 
 x-esi-request-id: 9e607ee9-a27b-49ca-8fe5-ae107b42def7

Body

This is just an example as the problem is not the actual response since it works correctly, just not with the right info

{
  "solar_system_id": 30003502
}

Expected

The correct solar_system_id

Checklist

Check all boxes that apply to this issue:

• Bug description is provided
• Request path is provided
• Response status code is provided
• Response headers are provided
• Response body is provided
• Expected response is provided

[Blacksmoke16]

@Redrazor Have you happened to do any abyssal sites?

[Redrazor]

@Blacksmoke16 None. I have never entered an abyssal and this is not related to abyssal being untracked at the moment. The system where it froze is j-space tough and happened between WH hoping.

[lukasni]

@Redrazor since this is a hard to reproduce error providing the Headers is pretty vital, even if there's nothing unusual, since it'll help CCP in finding out which requests are affected, specifically x-esi-request-id. I recommend editing the issue with the actual headers of a faulty response.

[Redrazor]

@lukasni Yes, I understand that. Unfortunately at the time I didn't copy the headers as I was still trying to determine if the error came from ESI or the 3rd party apps and I can't also reproduce it until it happens again. My hope was that the implementation for this specific call would be reviewed internally as to produce an hypothesis on why would the actual location of a player be frozen on a specific system when he/she is actually moving. Caching mechanics? Wrongful storage of timestamps? Hard to tell from outside. Thank you for the replies, tough.

[lukasni]

From the fact that mappers like Pathfinder, Tripwire et al. are largely operating without issue it follows that this bug isn't hugely common. It has all the makings of a monolith bug, but since it seems to occur only in very select circumstances the more detail the better to investigate it.

[bahrmichael]

Is there a way to identify that locations are frozen solely based on the resulting location ids (beware of the cache timer within which a character could travel through one or more systems)? If possible, I can try to find more examples through the clone guard app.

[Redrazor]

At the time I replicated this the location id persisted for several hours (until Down Time) when everything came back to normal. Could this be part of a call update? Is there any implementations that stop new responses from being generated if the call is ready to be replaced by a new version? I believe I may have had "this route has an available update" indicated on the headers as a warning but I cannot be 100% sure.

[lukasni]

There's only a v1 of GET /characters/{character_id}/location/, so that's unlikely

[Redrazor]

I'm actually experiencing the same thing at this moment so I've updated the bug with the correct headers

[bahrmichael]

I think I had this happen too. Added some request logging for the next times.

[Risingson]

I had this happen once. location got stuck at where my clone woke up after having been podded in abyssal.

[Redrazor]

Just to reinforce: I have not done abyssal (ever), I have not been podded or jump cloned. Normal use of Tripwire plus 3rd party Corp tool. Both + https://esi.evetech.net/ calls return a system where I am not currently in but was previously.

[orb]

I am having this problem today. Character location and ship type are not updating in ESI.

As requested in #esi in tweetfleet, I reported in game. EBR-157771.

I believe this is also happening with my calls to the bookmark API, which is in a separate oauth app.

UPDATE:
I updated the app settings at https://developers.eveonline.com/ for the bookmarks app, and as soon as I did that I started getting current data. I don't control the token used for failing calls in the EBR (it's a call being made by tripwire) to verify that it does or doesn't change anything.

UPDATE 2:
After downtime, my location and ship type are again updating. I hope the details in the EBR help track this down.

[ddavaham]

Duplicate of #828

[chigaze]

Failing to see how this is a duplicate of 828 given it occurs without being podded or having clone jumped. I have had this happen on a number of occasions. I have reported it CCP but never had a response.

[ddavaham]

Please redirect all comments on location data from the /characters/{character_id}/location endpoint being frozen to the current issue that is open, which has been linked for your convenience above.