Bl4ckH4wkGER

That's correct and expected. It was the compromise we had to go with to get this greenlit by Legal. The alternative would have been no ability to designate a "don't show again".

I just tested the behavior on one of my test caches and it works as expected. Leave "Don't show again" unchecked and click OK=> next time I click the link the modal opens again. Check "Don't show again" and click OK => next time I click the link I'm taken straight there, no modal open. This functionality relies on a cookie and is good for 30 days once set for the link in question. Are you sure you're not blocking or deleting cookies after every session or one of your various scripts is interfering with the proper workings? Any of the latter may indeed render this non-functional for you.

I merged the various duplicate threads that were created in the last few days. We're aware and looking at a fix, thanks.

For years now you've been trying to add a Geocaching Event to the same local culture event "Heiliwog" that takes place every year around midnight when the church bells ring from December 24 to December 25. It's not the regular Christmas market event you're trying to sell it as. This isn't new and also not a recent change in the guidelines. You've been told that repeatedly by different local reviewers and HQ. Yet, here we are again with you acting surprised in the forums. This thread should be closed because of that.

Thanks for letting us know and especially to @baer2006 for the additional details, that makes our life a lot easier. I've created a ticket and will keep you posted once we have a fix.

@pwgo Thank for the additional details. We'll take another look and I will circle back once we have insights. No, I don't have a timeline at this point. @mbooda Thanks for the report. As noted before, resources we will spend on fixing the old seek/nearest based PQ preview will be limited vs the migration to the new search results. I hence don't know whether we will address this.

This has been fixed.

In the meantime, please feel free to use the Browse Map at https://www.geocaching.com/map

We're aware and working on a fix. Thank you for your patience.

As a separate announcement for this thread: The original release happened on October 18 and we're now on November 17. The month-long warranty period where bugs in this release were prioritized higher has ended. With that and the various upcoming holidays, any further bugs, unless deemed critical in priority, may hence take longer to fix. Thank you for your understanding.

For context - your previous issue was no issue in the PQ API - that part was functioning as expected. The issue was that the data for GC4YNCN in Elasticsearch (queried by the PQ API) was out of sync with what shows straight from the DB in other places on the website. Chances are 99% that the same is true for this new cache you found. While we will look into reindexing TB information in Elasticsearch, a lot of these issues will resolve themselves naturally over time. It's not scalable for us to manually reindex individual caches every time an odd-one-out is found. I'd consider it more crucial whether the PQ file contains duplicated. If so, that'd indeed by an issue, but not anything that showed in our tests. If you have cases where that is the case, it'd be great to get repro steps for those. Also note that as we had to completely rebuild how the route polygons are handled, there may by nature be slight deviations, especially toward the outside edges of the polygons. We may not be able to replicate the old implementation 100% but the current solution is very very close and actually provided better coverage in several areas. If that does not apply for your particular route that may be a case specific issue. Lastly, to my previous comments in this thread, the old seek/nearest implementation is quite brittle. Hence resources spend on fixing it vs. spending that time on migrating these elements to the new pages will be limited.

Today we released a number of bug fixes: User route PQs should include the expected number of results again PQs should no longer run immediately vs on the selected days They no longer include Events when Events are not selected as a cache type PQs limited to caches with TBs no longer contain caches without TBs They exclude caches with ANY of the selected attributes PQs no longer include caches from the ignore list A Wherigo Cache is no called that in the <type> tag

The next sprint release will be Wednesday, November 16. It will also include a fix for the bug you're mentioning. Thank you for your patience.

Yeah I can reproduce that. As noted in my earlier post here, the seek/nearest page is very brittle. Some more context: With every page change or sorting, the whole page and data reloads. Some things are stored in memory, some things are cached on a server. Yet, every time the page reloads it's basically a roll of the dice whether you get the same server again and things continue or whether things reset. Based on all that, I won't continue the game of whack-a-mole and continue holding together seek/nearest with duct tape and zip ties. We'll spend the time to migrate PQ previews to the new search results instead as that is the more scalable long-term solution. Thanks for your understanding. @HHL Thanks for the additional examples. We've identified the issue and a fix is in progress. No need for further examples at this point. Thank you for your patience. @little-leggs I confirmed that they used to behave the same before as they do now. Both PQs and the regular old search use the seek/nearest pages with similar URLs and the same user interface. It's easy to confuse the two. Are you sure you weren't viewing a regular old search for those purposes before? Those would have access to the full 15000 results in your home zone also and yield different results - ones more in line with the new search interface. In an attempt to clarify once more: Your 40 mile home zone has 15000 caches in it. When taking taking your home coordinates as a reference point, any search will initially return the same 1000 caches - the 1000 closest to your home coordinates. Now, PQs save the above (1000 closest to home coords) as a snapshot If you then sort across the PQ snapshot, it only has access to said 1000 caches. Any secondary sorting, e.g last found, can still only look at the 1000 caches. Search will actively adapt the 1000 cache sub-selection of the 15000 total based on your secondary sorting. The default 1000 by distance will match the PQ. If you then switch your sorting to any other reference, it may select a different subset of 1000, leading to results different to the PQ snapshot.

That highly depends on whether you've set them up for the same search radius around your home coordinates. Your PQ is limited to 40 miles around your home coordinates. Can you confirm that the same is true for the regular search? (By default it runs a global search that would yield a lot more results.) Even if you run the original search based on the same 40 mile radius, there are almost 15000 caches in that radius. PQs will always pick the first 1000 by distance around the reference point. This is finite and cannot be modified further - PQs are a snapshot in time. Search, depending on how you filter it, will return the 1000 that is most relevant to your additional filtering. So you may get a different set of 1000 from the 15k total if you filter additionally on Last Found vs Distance. That is the benefit of Search being dynamic vs a finite snapshot by distance. I don't see anything wrong here.

@newbie52 Please see my last comment in the post above yours. It's a known issue with the current system. We're working on a fix.

@HHL Thanks for your report and the extensive documentation. It appears that while we fixed things with the "include all" aspect of attributes, there is still something amiss with the "exclude all" aspect. @little-leggs Unfortunately you're still not including screenshots so my best guess is that you're talking about the PQ preview in old seek/nearest: Without knowing exactly what PQ you're looking at or whether you're actually looking at an actual PQ vs just some other search results, it's hard to troubleshoot. That said, clicking on "Last Found" would always sort the results on the "Last Found" date in either ascending or descending order. If there were unfound caches, you'd see them at the top when sorting in ascending order. Based on my tests that still works as expected. I can't speak for how many clicks it used to take vs does take but am not aware of us having changed this part of the behavior. As noted above, the sorting still works. @pwgo As noted in my post from November 2, we've identified the issue, so no further help is needed at this point. A fix will require rebuilding the polygon service that creates the coverage along the route. This is a larger ask and hence this one is taking a little longer.

@RCH65 Thanks for bringing that up. This is one of several cache type related changes and is intentional. Some Event types also got updated to newer more accurate names. Overall, the names now more closely align with what you see on your Profile, Statistics, etc. Let me know if there are any questions.

Please read my comment again. I'm not saying anything about PQs going away. I'm explicitly saying to migrate the PQ preview from the old buggy seek/nearest platform to the modern next.js search results. Knowing the mess that is the old seek/nearest code-base, I doubt it's that simple. I responded to similar claims here before: Yes it was working before when two ancient ca 2005 code bases were working together. Some of these issues are side-effects of trying to get a 2005 and a vastly different and advanced 2022 version to talk to each other. The best course of action would be to get two modern systems that are much more compatible to work together. That is the next step. For the present issue, while I understand your frustration, I offered you a clear workaround. If instead of continuing to have a productive conversation like we did up until this point , you'd rather point fingers and speak poorly about the people who are trying to help you, let me know and we can be done here. And to those who say "don't take it personal" - thanks, I'll stand up for my developers and QA engineers any day because I know how hard they work every day within the constraints of our systems.

Thanks for the additional details. Frankly they still make my head hurt due to the sheer number of steps and back and forth needed to get things to break. While I will pass it on, I'm not going to make promises that we will fix this one as it is a bit of an edge case. The time may be better spent on migrating PQ previews to the new search results - which will be the goal down the road anyway. In the meantime, it would be easier if you set up individual PQs for your three scenarios instead of all the switching around of reference points.

Thank you for the additional details. I can reproduce the issue with these repro steps. I will create a ticket to get this addressed

I can't reproduce this so far. If I create a new standard PQ against my home coords and just check the "Has Trackables" filter, all works as expected: I only see caches that have TBs. I will need additional details of what other filter you have selected and ideally screenshots, not just the PQ-id link. The PQ preview code is based on the old seek/nearest search, which frankly is a mess and long overdue to be retired. Amongst other things, it uses a bunch of client & server caching that may interfere with how the data you're seeing is presented. That said, I cannot follow your description quite, yet. I'm also unclear of what you consider "old results" and "new results". Again, please provide step-by-step instructions and screenshots.

We have deployed a hot fix for this. The issue was caused by not all PQs populating the distance column. To clarify, PQs created with the following don't do so - both in the old and in the new experience (we verified this against the old code in a sandbox): PQs with "From Origin -> None Selected" PQs created from Lists PQs for caches along a route Thank you for the additional details. I was able to reproduce the issue and have created a bug ticket for us to fix. I'm sorry, I am unable to follow what you're describing. Please compare your report to the other reports in this thread and try again. I'd be happy to help once we have a complete report.

Thanks for the report. That looks like a regression that slipped through the cracks. We'll continue our game of Whac-A-Mole.

@mbooda Following up with you specifically. If we run both of the PQs you shared, we're not getting Events - as expected and as designated in your criteria. Likewise, we cannot reproduce the issue with something scheduled for later running right away. Could you please share additional screenshots of the setup, the preview, the results of an example PQ that exhibits the issue? Ideally step by step instructions would be great to help us reproduce. If we aren't able to reproduce the issue, we aren't really able to address it unfortunately.