Bug: Deleting and re-logging a find doesn't reinstate treasure

[+bapboy1996]

Replication Steps:

• Log a find on a cache that earns a treasure (and verify the earned treasure)
• Delete the log
• Note that the treasure has been removed
• Log a find on the same cache

Expected Outcome: The treasure should be reinstated when the qualifying find is re-added

Actual Outcome: The treasure is not reinstated

 

This occurred to me on GCB6KF3, with treasure Mystery Books, although I imagine that it could be replicated on any treasure-qualifying cache.

 

Usually when logging an FTF, I'll post an "FTF, full log to come" found it log, and then delete it later and post the full log. 

Because of this bug, I'm instead posting a write note, which I'd prefer not to do, because the cache doesn't show as found on pocket queries.

Edited May 12 by bapboy1996
Add more information

[geoawareUSA9]

This isn't a bug. It's to keep people from logging caches just to get treasures and then deleting their logs.

 

Next time edit your log instead of deleting it, and the treasure will stay.

[+Max and 99]

From the blog:

 

If a log is deleted, the Treasure collected from that log is removed. To collect the Treasure again, find and log a different geocache that meets the criteria.

[Nylimb]

8 hours ago, geoawareUSA9 said:

This isn't a bug. It's to keep people from logging caches just to get treasures and then deleting their logs.

I don't understand that.  Of course the system should delete the treasure if the user deletes the log.  But why shouldn't it re-award the treasure when the user posts a new log for the same cache?

[Moun10Bike]

1 hour ago, Nylimb said:

I don't understand that.  Of course the system should delete the treasure if the user deletes the log.  But why shouldn't it re-award the treasure when the user posts a new log for the same cache?

 

It doesn't seem to make a lot of sense right now when the collection rules are fairly basic, but in the future, there are plans for more random awarding. Without this preventative measure, people could repeatedly log and delete to "fish" for the treasure they desire.

That said, the engineers are looking at ways to improve this functionality and avoid the penalty that comes with deleting a log.

[Nylimb]

On 5/12/2025 at 2:48 PM, Moun10Bike said:

 

It doesn't seem to make a lot of sense right now when the collection rules are fairly basic, but in the future, there are plans for more random awarding. Without this preventative measure, people could repeatedly log and delete to "fish" for the treasure they desire.

That said, the engineers are looking at ways to improve this functionality and avoid the penalty that comes with deleting a log.

Thanks.  I'm glad to know that the engineers are working on it.

 

Personally, I'd prefer not to have randomness involved.  For me it would be more fun to plan ahead, by knowing in advance which treasure collection a cache find will be applied to.

But I can see how wanting randomness makes re-awarding difficult:  Even if the website bases its pseudorandom decision on a hash function of, say, the user's ID, the cache's GC number, and some sort of IDs for the existing treasure collections, it's possible that a future collection would also accept that cache as a qualifier, so deleting a log and entering a new one could change which collection the cache is applied to.

[+Hügh]

On 5/15/2025 at 4:10 PM, Nylimb said:

Personally, I'd prefer not to have randomness involved.  For me it would be more fun to plan ahead, by knowing in advance which treasure collection a cache find will be applied to.

 

I agree, but I'll accept that it's part of the branding that it's random (you don't know what swag you'll find in a cache).

 

On 5/15/2025 at 4:10 PM, Nylimb said:

Even if the website bases its pseudorandom decision on a hash function of, say, the user's ID, the cache's GC number, and some sort of IDs for the existing treasure collections, it's possible that a future collection would also accept that cache as a qualifier, so deleting a log and entering a new one could change which collection the cache is applied to.

 

One solution would be to always pick the collection deterministically, either by:

• always trying to match a cache against the oldest collection set's criteria before moving on to newer collections;
• use a pseudorandom number generator to choose amongst the collections the user has available; or
• forcing the user to nominate a particular collection to work on at any one time (in the original announcement podcast, they discussed the possibility of limiting users to working on at most 2-3 collections at once - so slightly more complicated.)

An issue with (2), of course, is that if a log is deleted long after it is posted, the user's available collections will be wildly different leading to an inconsistent result.

 

The best solution would be to store, with every log, which treasure it awarded. When a new "Found It" log is posted, the system would look through archived logs to see if the user has previously been awarded treasure for that particular cache, and then award them the same one. It would work out to something like 8 bytes per log, so ~1.5 billion logs * 8 bytes is roughly 12 GB of immediate data. Alternatively, you could create a table mapping geocaches and players to treasures, and store in that table the treasure a player was awarded for logging a particular cache. This would persist even though log deletion, so you can check that table to see if the treasure-awarding algorithm has already decreed a particular treasure for a particular geocache + player combination. If a user found a cache prior to the release of treasures, it can be assumed that no treasure was awarded for that find.

 

If that's too much data, you could store these associations only for some time (ie. 48 hours - and force users to re-log within this timeframe if they wish to reclaim their treasure) like this:

• When a log is deleted, check if it awarded treasure. If it did, store in the database that that (now-deleted) log awarded treasure X.
• When a "Found It" log is posted:
  • If the user has never posted a log on this cache before, award them Treasure following the normal algorithm.
  • If the user has a deleted log on this cache AND that log was deleted in the last 48 hours, then look up the Treasure that they were awarded in the database and re-award them that same treasure. If it's been more than 48 hours then the user loses out on the treasure.
• Clean out records older than 48 hours every so often.

Edited June 11 by Hügh