Change History

That seems to be a case of data being obsolete/old in Project-GC. And also "out of sync". When I updated the data for GCNXZ7 the owner_id change to 1. So Project-GC has this far, somehow, found that the user 264059 doesn't exist anymore. At that time it doesn't update any geocaches though.

Unrelated to that, the geocache will be updated at a certain point, and then the API will tell Project-GC that user 1 owns the geocache.

This is a bit of mess, mostly because we aren't in control of the data.

But yes, this leads to the fact that a, by GetFinds(), returned user-id can be a >1 integer, that ProfileId2Name() will later on return false for, because that user doesn't exist.

I just checked the database, there seems to be 50 (plus the user-id 1 user) user-ids in the table for geocaches that does not exist in the users table, right now.

[b]There is a cleanup function being run whenever Project-GC discovers that a user has been deleted. I will add some code into that function that removes all known ownership' of geocaches as well. I will make the patch go live the coming 15 minutes, and also schedule an update for all geocaches owned by such accounts.[/b]

The fact that false is returned will probably be something that can still happen, though it will probably be a [b]lot[/b] less likely. First off, the above isn't happening in a transaction, so there is a slight moment that the data will still be like today. There might also be other reasons for this happening that I can't recall right now.

PS! Great case you served me. When I had read your post 2-3 times I could imagine what the actual issue was, and confirm it by just 1-2 minutes of work. Sometimes it's hard to find the odd cases myself, Project-GC has grown a bit too large in that way. And the whole GDPR-concept has added quite a lot of complexity on top of things.

That seems to be a case of data being obsolete/old in Project-GC. And also "out of sync". When I updated the data for GCNXZ7 the owner_id change to 1. So Project-GC has this far, somehow, found that the user 264059 doesn't exist anymore. At that time it doesn't update any geocaches though.

Unrelated to that, the geocache will be updated at a certain point, and then the API will tell Project-GC that user 1 owns the geocache.

This is a bit of mess, mostly because we aren't in control of the data.

But yes, this leads to the fact that a, by GetFinds(), returned user-id can be a >1 integer, that ProfileId2Name() will later on return false for, because that user doesn't exist.

I just checked the database, there seems to be 51 50 (plus the user-id 1 user) user-ids in the table for geocaches that does not exist in the users table, right now.

[b]There is a cleanup function being run whenever Project-GC discovers that a user has been deleted. I will add some code into that function that removes all known ownership' of geocaches as well. I will make the patch go live the coming 15 minutes, and also schedule an update for all geocaches owned by such accounts.[/b]

The fact that false is returned will probably be something that can still happen, though it will probably be a [b]lot[/b] less likely. First off, the above isn't happening in a transaction, so there is a slight moment that the data will still be like today. There might also be other reasons for this happening that I can't recall right now.

That seems to be a case of data being obsolete/old in Project-GC. And also "out of sync". When I updated the data for GCNXZ7 the owner_id change to 1. So Project-GC has this far, somehow, found that the user 264059 doesn't exist anymore. At that time it doesn't update any geocaches though.

Unrelated to that, the geocache will be updated at a certain point, and then the API will tell Project-GC that user 1 owns the geocache.

This is a bit of mess, mostly because we aren't in control of the data.

But yes, this leads to the fact that a, by GetFinds(), returned user-id can be a >1 integer, that ProfileId2Name() will later on return false for, because that user doesn't exist.

I just checked the database, there seems to be 51 user-ids in the table for geocaches that does not exist in the users table, right now.

[b]There is a cleanup function being run whenever Project-GC discovers that a user has been deleted. I will add some code into that function that removes all known ownership' of geocaches as well. I will make the patch go live the coming 15 minutes, and also schedule an update for all geocaches owned by such accounts.[/b]

The fact that false is returned will probably be something that can still happen, though it will probably be a [b]lot[/b] less likely. First off, the above isn't happening in a transaction, so there is a slight moment that the data will still be like today. There might also be other reasons for this happening that I can't recall right now.

That seems to be a case of data being obsolete/old in Project-GC. And also "out of sync". When I updated the data for GCNXZ7 the owner_id change to 1. So Project-GC has this far, somehow, found that the user 264059 doesn't exist anymore. At that time it doesn't update any geocaches though.

Unrelated to that, the geocache will be updated at a certain point, and then the API will tell Project-GC that user 1 owns the geocache.

This is a bit of mess, mostly because we aren't in control of the data.

But yes, this leads to the fact that a, by GetFinds(), returned user-id can be a >1 integer, that ProfileId2Name() will later on return false for, because that user doesn't exist.

I just checked the database, there seems to be 51 user-ids in the table for geocaches that does not exist in the users table, right now.

[b]There is a cleanup function being run whenever Project-GC discovers that a user has been deleted. I will add some code into that function that removes all known ownership' of geocaches as well. I will make the patch go live the coming 15 minutes, and also schedule an update for all geocaches owned by such accounts.[/b]