Re: Challenge Checker for GC4QPP7 - The Western Washington Tree Species Challenge

Hi,

I am attempting to use this challenge checker but it is not working:
https://project-gc.com/Challenges/GC4QPP7/72455

Both my caching partners can run the checker and get results no problem but it gives me an error message every time I try and run it. Can you please take a look at it and see if something is wrong?

Thanks,
Mike.

I have asked the scriptwriter to have a look at this

Thanks!

I run the checker from my browser using my username and it times out. If I run the checker using my caching partners names it works fine. I have tried logging out, restarting, etc but it hasn't helped.

I am also having the same problem for https://project-gc.com/Challenges//69022

Looks like cache.owner_id is no longer `nil` if the cache owner is a [DELETED_USER]. This contradicts https://project-gc.com/forum/read?6,61592. Further, PGC.ProfileId2Name returns `false` if the supplied `id` refers to a [DELETED_USER].

I've fixed my script, but I suspect that the other script has a different bug in it.

Hügh Wrote:
-------------------------------------------------------
> Looks like cache.owner_id is no longer `nil` if
> the cache owner is a [DELETED_USER]. This
> contradicts
> https://project-gc.com/forum/read?6,61592.
> Further, PGC.ProfileId2Name returns `false` if the
> supplied `id` refers to a [DELETED_USER].
>
> I've fixed my script, but I suspect that the other
> script has a different bug in it.

Without double checking the code to much, it sounds like I haven't been clear enough in the post you referred to. The post you refer to describes the behavior of method GetFinds(). GetFinds() returns null/nil as owner_id for deleted users. If then sending null/nil into PGC.ProfileId2Name() the code will fail.

PGC.ProfileId2Name() returns false when the user doesn't exist, either if it's an invalid ID (never existed) or an ID of a former user.

Does this clear things up, or shall I investigate the code and actual examples that aren't working as expected?

That is not what I am seeing. I added the following debugging lines to my script:

    PGC.Log(cache.gccode); PGC.Log(" ");
    PGC.Log(cache.owner_id); PGC.Log(" ");
    PGC.Log(PGC.ProfileId2Name(cache.owner_id)); PGC.Log(" ");
    PGC.Log(type(PGC.ProfileId2Name(cache.owner_id))); PGC.Log("\n");

This should print the GC code, owner_id, ProfileId2Name(owner_id), and the type of the value returned ProfileId2Name.

When I run this script on "msweetnw", the following is output:

...
GC59R81 6003785 MBIC-BLM string
GCNXZ7 264059  boolean
GC3ZCAB 340633 Curious Joe string
...

Note that GCNXZ7 is placed by [DELETED_USER] according to Geocaching.com. However, the owner_id (264059) is returned. Further, passing this owner_id into ProfileId2Name returns a boolean false.

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.

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.

The fact that false is returned will probably be something that can still happen, though it will probably be a lot 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.



Edited 3 time(s). Last edit at 11/08/2022 01:24PM by magma1447. (view changes)

Ah, that would explain that. Thank you.

All such owners has now been removed from the database. The only user-id owning geocaches that doesn't exist in the user-table is owner-id 1. Let's hope it stays that way, so I didn't miss any case.

I have confirmed that the challenge script is generally working - however produces odd results starting at msweetnw's 263rd find which is, I suspect, the first occurrence of a qualifying cache. I don't have much time to delve into this, so will take a few days. Won't be long...

Thanks everyone!
My 262nd find was GC55ZRX B14: Pinecone Burke Mountain https://www.geocaching.com/geocache/GC55ZRX
My 263rd find was GC3FPB4 Forest HideAway https://www.geocaching.com/geocache/GC3FPB4

Looking into it tonight...

@the Seagnoid - What is the situation on this topic