Jump to content

Release Notes (Website: Pocket Query API) - October 18, 2022


Followers 7

Recommended Posts

With today’s release, we are making key improvements to the Pocket Query API, aka part of the infrastructure powering Pocket Queries behind the scenes.

 

The user interface, including how and where you can create Pocket Queries, will remain unchanged. Pocket Queries will remain available to API partners and scheduled queries will continue to be generated around midnight Pacific Time.

 

Players should benefit from Pocket Queries generating more quickly and more reliably going forward. If you experience any unexpected behavior, please let us know in the comments below.

 

Please see this Help Center article for more details about Pocket Queries. 

 

Sven (Bl4ckH4wkGER) is watching this thread to answer questions whenever possible.
 
Any posts in this thread should relate to features in this release. Comments unrelated to the release may be removed. Please direct unrelated comments to other appropriate threads. Thanks!
 

  • Helpful 2
Link to comment

Yesterday I added 4 PQs. After some minutes, they showed up as done, I was able to download it via browser. Another hour or so later, I wanted to download it to GSAK, I got an error 404 not found, also with c:geo. I can not see them till now, they are simply not in the download list. 
Older ones are still available, the ones from today also, but the ones I ran yesterday night (UCT+1, server around 13:00) are not available via webpage or applications. This is quite annoying, since I would have needed them today.

I am still wondering, if someone tests the code before release. :lostsignal:

Edited by DaTechniker
Link to comment

@Pe_Bo @6foot3

Thank you for bringing that to our attention.

Could you confirm for me that the later pages contained PQs that recently ran vs old records of PQs you ran a long time ago. Very old PQs may have not gotten ported over to the new systems.

 

I will check with the engineers on this but any additional context and detail you can provide would be helpful, thanks.


@DaTechniker @Gamma5

 

API partners were given advance notice of these changes. GSAK is still actively working on making the needed adjustments on their end. Once they have a patch, they will let the community know and things will be back to working as you are used to

 

As far as the mentioned unauthorized application goes, we don't test for dependencies against them and they're not given advance notice. Please reach out to them directly about any issues. That said, I don't think expecting a fix from them within less than 24 hours is fair. Please note that any further discussion of issues with this application will have to be deleted because they violate forum guidelines.

 

In the meantime you can download the PQs via the browser on the website. If you are still missing PQs on the web also, please provide more detail about which ones are missing in particular, ideally provide the PQ ID, and when you would've expected them so we can take another look.

  • Upvote 1
  • Helpful 1
  • Love 1
Link to comment
8 minutes ago, Pe_Bo said:

New or old PQ doesn't seem to matter. The site change that caused the error was made less than 24 hours ago.

 

Thanks. I misread your original report.

I was able to repro the issue with a new PQ, too, and have created a ticket for the engineers.

  • Helpful 2
Link to comment
59 minutes ago, Bl4ckH4wkGER said:

@Pe_Bo @6foot3

Thank you for bringing that to our attention.

Could you confirm for me that the later pages contained PQs that recently ran vs old records of PQs you ran a long time ago. Very old PQs may have not gotten ported over to the new systems.

 

I will check with the engineers on this but any additional context and detail you can provide would be helpful, thanks.


@DaTechniker @Gamma5

 

API partners were given advance notice of these changes. GSAK is still actively working on making the needed adjustments on their end. Once they have a patch, they will let the community know and things will be back to working as you are used to

 

As far as the mentioned unauthorized application goes, we don't test for dependencies against them and they're not given advance notice. Please reach out to them directly about any issues. That said, I don't think expecting a fix from them within less than 24 hours is fair. Please note that any further discussion of issues with this application will have to be deleted because they violate forum guidelines.

 

In the meantime you can download the PQs via the browser on the website. If you are still missing PQs on the web also, please provide more detail about which ones are missing in particular, ideally provide the PQ ID, and when you would've expected them so we can take another look.

I am not sure, if my last post was deleted or not sent, so I will try again.

Yesterday ran 6 PQ in the morning and 4 in the evening.  Today I am able to download 4 of the old ones (1 was updated today and I can not check at the moment). One of the early ones, and all of the evening one can not be downloaded from the geocaching website, no application involved, anymore. Todays are working fine, and older ones also. So I am asking if it is planned to make the run but not downloadable PQs, that were filling up my quota of possible daily PQs, be made available again or not. 
IMHO this is a valid question and no violation of guidlines. I get 10 PQs from GC per day, but I got only 5 to 6 available on the webpage for download and this is a technical fact, nothing else.

Link to comment

My PQ for Traditionals is defined to deliver only caches with sizes "Large", "Regular" or "Small". So it should exclude Micros.

This has worked fine ever since. Today it is broken. I get only "Micro" caches.  So it delivers the opposite of the intended result.

Attached screenshot for PQ definition and result.

Any Idea?

 

SuchePQ.jpg

ErgebnisPQ.jpg

  • Helpful 1
Link to comment
6 minutes ago, DaTechniker said:

I am not sure, if my last post was deleted or not sent, so I will try again.

Yesterday ran 6 PQ in the morning and 4 in the evening.  Today I am able to download 4 of the old ones (1 was updated today and I can not check at the moment). One of the early ones, and all of the evening one can not be downloaded from the geocaching website, no application involved, anymore. Todays are working fine, and older ones also. So I am asking if it is planned to make the run but not downloadable PQs, that were filling up my quota of possible daily PQs, be made available again or not. 
IMHO this is a valid question and no violation of guidlines. I get 10 PQs from GC per day, but I got only 5 to 6 available on the webpage for download and this is a technical fact, nothing else.

 

I can understand your frustration, especially if this compromised your planning and even more so if the tools you are usually using haven't adjusted to this update, yet.

 

That said, in the interest of actually being able to help you I'd ask you to remember that "wie man in den Wald hinein ruft, so schallt es heraus".

 

Back to your issue:

 

It is possible that depending on timing, those queries got caught up in the system switchover.

While the new system - this includes a new storage solution - was pre-populated with all scheduled PQs of nightly runs, if you ran a manual PQ shortly before the switch, it may have happened that this was saved in the old system still. When we then switched the systems, and hence the path to the new storage system, it may have become unavailable.

 

To fully understand what happened , we will need the PocketQuery IDs for these queries, as noted in my earlier post.

 

In case you don't know how to retrieve them, here is how:

  • Click on the preview icon of the PQ to open the preview
  • Copy the ID from the URL
  • Share it with us here

GetPQid.png

 

Unfortunately, we won't be able to manually reset your daily PQ allocation for past days. 

  • Helpful 1
Link to comment
2 hours ago, eM.und.eS said:

My PQ for Traditionals is defined to deliver only caches with sizes "Large", "Regular" or "Small". So it should exclude Micros.

This has worked fine ever since. Today it is broken. I get only "Micro" caches.  So it delivers the opposite of the intended result.

Attached screenshot for PQ definition and result.

Any Idea?

 

Thank you for bringing that to our attention.
 

I will create a ticket so we can get that fixed.

  • Helpful 3
Link to comment
2 hours ago, Bl4ckH4wkGER said:

 

I can understand your frustration, especially if this compromised your planning and even more so if the tools you are usually using haven't adjusted to this update, yet.

 

That said, in the interest of actually being able to help you I'd ask you to remember that "wie man in den Wald hinein ruft, so schallt es heraus".

 

Back to your issue:

 

It is possible that depending on timing, those queries got caught up in the system switchover.

While the new system - this includes a new storage solution - was pre-populated with all scheduled PQs of nightly runs, if you ran a manual PQ shortly before the switch, it may have happened that this was saved in the old system still. When we then switched the systems, and hence the path to the new storage system, it may have become unavailable.

 

To fully understand what happened , we will need the PocketQuery IDs for these queries, as noted in my earlier post.

 

In case you don't know how to retrieve them, here is how:

  • Click on the preview icon of the PQ to open the preview
  • Copy the ID from the URL
  • Share it with us here

GetPQid.png

 

Unfortunately, we won't be able to manually reset your daily PQ allocation for past days. 

Thanks for checking, here the PQ links:
image.png.7cb5e1935144528479a5ae1fbc488df5.png
neue
https://www.geocaching.com/seek/nearest.aspx?pq=a266324e-3d78-4297-84c0-280578c65dbe
https://www.geocaching.com/seek/nearest.aspx?pq=ebfae5ff-3256-4598-baf6-9dbb553dd2ac
https://www.geocaching.com/seek/nearest.aspx?pq=b84bc198-762a-4326-9217-b428e9f73bbc
https://www.geocaching.com/seek/nearest.aspx?pq=a68f44b4-4dbd-4730-b397-f68bfa9627cb
alte
https://www.geocaching.com/seek/nearest.aspx?pq=1c230007-b6b9-4832-84ea-a497836cd8a7

All links are from yesterdaysPQs, today everything worked as expected. Yesterday I also got the notification mails, but later no download also. 
image.thumb.png.b289c9c21cbcace20ec4ea0fa610f2fc.png

To be aware of such things, is there some feed or mailing list, to know, when updated to the website is done, so I may be warned before and expecting problems? 
One thing I like is, now links are https, so the browser is not complaining with every download via mail link.

Link to comment
22 minutes ago, DaTechniker said:

 

Thank you for sharing them. I have passed them on to the engineer working this project and we will see whether we can re-trigger them.

 

22 minutes ago, DaTechniker said:

To be aware of such things, is there some feed or mailing list, to know, when updated to the website is done, so I may be warned before and expecting problems? 

 

The only way would be the strategy proposed by @HHL

 

22 minutes ago, DaTechniker said:

One thing I like is, now links are https, so the browser is not complaining with every download via mail link.

 

The download issues were present in all Chromium based browsers but not in Firefox before and due to a Google decision to block HTTP downloads - as used by the old Pocket Query storage. 

 

It is correct that with the new Pocket Query storage using HTTPS download paths that will no longer be an issue.

Link to comment
4 hours ago, Bl4ckH4wkGER said:

API partners were given advance notice of these changes. GSAK is still actively working on making the needed adjustments on their end. Once they have a patch, they will let the community know and things will be back to working as you are used to

Just to be clear. Yes, GSAK did get advance notice of the changes, thank you, and have tested with the new format. Pocket Query loading into GSAK works correctly with  PQs from the new server both as a manual GPX import and as a direct import through the Geocaching.com API menu. The only items that need to be patched are the names of the special 'Celebration' cache types. Those type names have changed in the new PQs but have not yet changed to match in the API. GSAK is limited to one cache type name per cache type and will issue a patch when the API matches the PQs.

For now those rare caches will import into GSAK with  the correct cache type name from the API but with cache type 'unknown' from the new PQs. We thought it better that the API should be the arbiter of type names as it is often what folks use to refresh caches more often than they get PQs. Downloading a PQ with these cache types and then subsequently refreshing with the API will correct the cache type names.

 

These are the changes that were made :

 

"Lost & Found Celebration" is now "Community Celebration Event"

"Groundspeak HQ" is now "Geocaching HQ Celebration"

 

All other cache types (the vast majority of caches) will import into GSAK with the correct types.

  • Love 2
Link to comment

Thank you for the clarification @Lignumaqua.

At the time of my original post it wasn't fully clear to me, yet, whether the download failed on the GSAK API end for the player in question or whether it was something with the file to begin with. This has since clarified itself with the more recent exchanges. No finger pointing at GSAK intended :) 

 

Regarding the cache type name changes, we do have a ticket for that and Annie will let you know once it's been adjusted on the partner API.

 

Link to comment

@DaTechniker

My original suspicion about those Pocket Queries getting missed in the file system switch because they were run so shortly before it was correct.

We have manually retriggered them and they should now be rerun and available for download for you.

Please note that this should not count against your 10 PQ/ day allocation.

Thank you for your patience.

@all

We're working on fixes for the other two bugs (preview issues & sizing filter) and I will let you know once those have been resolved, too.

  • Helpful 1
Link to comment

I am no longer able to load today's PQs into Garmin MapSource. Error message pops up say "<filename> could not be imported." I never had an issue loading a GPX file before. I can load other GPX files fine. I can load the PQ into GSAK and then export to a GPX and that GPX loads fine, but that would be a pain to have to do that extra step every time.

Link to comment

I have a PQ (running daily), which gets me all caches (except mysteries) in a radius around my home. Therefore it has the "Event Cache" type checked, which should include Community Celebration Events. However, CCEs are ...

- not included in the "Preview" on the website

- not included in the actual GPX file generated by the PQ

They are included when mapping the PQ, though (including the one's on my Ignore List, which is an old bug).

  • Funny 1
  • Helpful 1
Link to comment
16 hours ago, res2100 said:

I am no longer able to load today's PQs into Garmin MapSource. Error message pops up say "<filename> could not be imported." I never had an issue loading a GPX file before. I can load other GPX files fine. I can load the PQ into GSAK and then export to a GPX and that GPX loads fine, but that would be a pain to have to do that extra step every time.

 

Hard to say what is the issue without comparing the exact PQ output that you got from the directly downloaded file vs your GSAK GPX export.

 

The new PQ files are every so slightly different to the old versions because of different systems and data formats involved. It may be that Garmin needs to update MapSource to account for those small changes.

 

You could help us by copying the two texts into a tool like https://www.diffchecker.com/ and share the differences here or reach out to me via PN so we can find a way for you to send me the two files.

 

7 hours ago, baer2006 said:

I have a PQ (running daily), which gets me all caches (except mysteries) in a radius around my home. Therefore it has the "Event Cache" type checked, which should include Community Celebration Events. However, CCEs are ...

- not included in the "Preview" on the website

- not included in the actual GPX file generated by the PQ

They are included when mapping the PQ, though (including the one's on my Ignore List, which is an old bug).


Thanks for the report. I have create a ticket with our engineers to make sure that all Event types are correctly covered by PQs as advertised in the setup menu (*includes: Geocaching HQ Block Party, Cache In Trash Out Event, Giga-Event Cache, Community Celebration Event, Geocaching HQ Celebration, Mega-Event Cache).

  • Helpful 1
Link to comment

When will this PQs with 'zero' results issue be resolved exactly?

 

For the last 2 days, I am getting zero results for all my REGULAR PQs.  My ROUTE based PQs are running fine.


Here is an example:

USA-Wyoming
https://www.geocaching.com/pocket/gcquery.aspx?guid=cc84a635-a100-4789-adca-c876e276fffd

 

This PQ Ran on 2022/10/20 00:26:37 and resulted in zero waypoints.

When I try to download it directly from the website, I get:

Sorry, the requested Pocket Query download is no longer available.

I am assuming this is because it has zero waypoints in it.

 

Thanks

 

 

Capture d’écran 2022-10-20 114036.png

  • Helpful 1
Link to comment

@Gamma5

Thank you for reporting this issue.

I see no prior mention of this from you or anybody else in this thread. The issues described by DaTechniker you had added a "+1" to before was a different one and the one empty query he encountered may have well been a glitch of us manually rerunning things.

 

Now that you've provided more details, including the exact setup of your query, we can better look into it. I will open a ticket to investigate. Thank you for your patience.

 

  • Upvote 1
  • Helpful 1
Link to comment
18 minutes ago, Bl4ckH4wkGER said:

@Gamma5

Thank you for reporting this issue.

I see no prior mention of this from you or anybody else in this thread. The issues described by DaTechniker you had added a "+1" to before was a different one and the one empty query he encountered may have well been a glitch of us manually rerunning things.

 

Now that you've provided more details, including the exact setup of your query, we can better look into it. I will open a ticket to investigate. Thank you for your patience.

 

 

Yes, sorry about that.  When I read the original post from DaTechniker, I had the same symptoms with GSAK  so I incorrectly assumed it was the same problem.

 

1909812877_Capturedcran2022-10-20121535.png.8e4799f12d4e80fa65b5976d36706507.png

 

Let me know if you need anything else from me.

 

  • Helpful 1
Link to comment
On 10/19/2022 at 2:07 AM, MartyBartfast said:

Odd, this is what I get when I click on the second page, but then clicking subsequent pages all display OK, including if I go back to the second page :

 

image.thumb.png.3a852dcfa6534aafdebab36555c6800e.png

This is still a problem when I go to run my pocket queries.  It is important to the way I use this site, since going to the last cache in the query tells me how far out my query goes and helps me determine if I need to do another query or not.  Please fix this.  Thanks!

Link to comment
23 hours ago, Bl4ckH4wkGER said:

Regarding the cache type name changes, we do have a ticket for that and Annie will let you know once it's been adjusted on the partner API

I’m confused, didn’t these name changes (and Geocaching HQ Block Party) happen in June 2019? Is something in the API going to change again?

 

Asking because a certain other API partner is probably still using cache type names where they really should use the corresponding id…

Link to comment
23 minutes ago, mustakorppi said:

I’m confused, didn’t these name changes (and Geocaching HQ Block Party) happen in June 2019? Is something in the API going to change again?

 

Asking because a certain other API partner is probably still using cache type names where they really should use the corresponding id…

I don't think so, the API returns, "Lost and Found Event Caches", and "LostAndFoundCelebration" as the cache types.

Link to comment
5 minutes ago, Lignumaqua said:

I don't think so, the API returns, "Lost and Found Event Caches", and "LostAndFoundCelebration" as the cache types.

I of course don’t have API access myself, but the change was discussed on another API partner’s forum back in 2019 (as the Groundspeak HQ —> Geocaching HQ name change broke their functionality). We are talking about this API, right? https://api.Groundspeak.com/documentation#geocache-types

Link to comment

@mustakorppi

Could you take that conversation offline, please?

The partner API is only indirectly related to this PQ API release. All API partners were given notice of the PQ changes and will be given notice of any other updates around cache types when they happen.

If you see issues with any partner applications, please direct that to them directly. Even if the API tells them one thing, they can always adjust the display text on the frontend.

Anyway, this isn't the place to dive into the partner API documentation.

 

Thank you for staying on-topic.

  • Upvote 1
  • Funny 1
Link to comment

I created a pocket query, downloaded and extracted the gpx files, but Garmin MapSource won't open them.  I can open older pocket query files without a problem.

 

Thank you for the GSAK work around, res2100!

 

Also, I created a Route pocket query about an hour ago and it still hasn't run.

Link to comment

The problem with Garmin MapSource is that it tries to validate the file before loading it.

 

And that's a problem because the new pocket query doesn't follow the schema it claims it should be validated against, i.e. http://www.topografix.com/GPX/1/0/gpx.xsd

Quoting the relevant bit of the schema here, the <xsd:sequence> indicates that the following elements should appear in the given order: name, desc, author...

<xsd:element name="gpx">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:string" minOccurs="0"/>
<!-- GPX file name -->
<xsd:element name="desc" type="xsd:string" minOccurs="0"/>
<!-- GPX file description -->
<xsd:element name="author" type="xsd:string" minOccurs="0"/>
<!-- GPX file author -->

 

But see how in new Pocket Queries the <author> element is out of order:

<gpx xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="1.0" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd http://www.Groundspeak.com/cache/1/0/1 http://www.Groundspeak.com/cache/1/0/1/cache.xsd" creator="Groundspeak Pocket Query" xmlns="http://www.topografix.com/GPX/1/0">
  <author>Groundspeak</author>
  <name>Belgia</name>
  <desc>Geocache file generated by Groundspeak</desc>

 

While waiting for HQ to fix this, you can open the gpx file in any text editor and cut the line

<author>Groundspeak</author>

and paste it after the line

<desc>Geocache file generated by Groundspeak</desc>

 

Save, and if you didn't make mistakes the file should open in MapSource.

 

 

 

 

Edited by mustakorppi
  • Helpful 3
  • Love 1
Link to comment
3 hours ago, KMacneal said:

Also, I created a Route pocket query about an hour ago and it still hasn't run.

 

Please let us know if you continue to see issues with this.

 

2 hours ago, mustakorppi said:

But see how in new Pocket Queries the <author> element is out of order

 

Thanks for digging into that. I'll create a ticket to see that we can get this back into the expected order.

 

  • Helpful 1
Link to comment
23 hours ago, Bl4ckH4wkGER said:

@Gamma5

Thank you for reporting this issue.

I see no prior mention of this from you or anybody else in this thread. The issues described by DaTechniker you had added a "+1" to before was a different one and the one empty query he encountered may have well been a glitch of us manually rerunning things.

 

Now that you've provided more details, including the exact setup of your query, we can better look into it. I will open a ticket to investigate. Thank you for your patience.

 

 

I can get results (non-zero count PQs) when I remove the ''Found in the last 7 days" option.

I need this option otherwise, my PQs exceeds 1000 caches.

 

Thanks for looking into it.

 

Capture d’écran 2022-10-21 112626.png

Edited by Gamma5
Link to comment
2 hours ago, Gamma5 said:

 

I can get results (non-zero count PQs) when I remove the ''Found in the last 7 days" option.

I need this option otherwise, my PQs exceeds 1000 caches.

 

Thanks for looking into it.

 

Capture d’écran 2022-10-21 112626.png

I can verify this behaviour with my recurring FOUND PQ
https://www.geocaching.com/seek/nearest.aspx?pq=1c230007-b6b9-4832-84ea-a497836cd8a7
https://www.geocaching.com/pocket/gcquery.aspx?guid=1c230007-b6b9-4832-84ea-a497836cd8a7
If I open the first link, I see founds, if I am doing the PQ in the second link, then it shows 0 founds
image.png.0419bf19dfe75ddaade913ef65691611.png
If I remove the Found in the last 7 days flag, I see 1000 caches:
image.png.cf5780af7fe6bcdd224fb5c965ec1db1.png

The preview shows results in both cases.

Link to comment

I found another bug with the the PQ exporter.
This time with events and CITO:
image.png.8899392c400a085957d66cc617f81438.png
I have this with 2 PQs today, One recurring for Austrian events, and one for London UK, for planning a trip.

I can see the CITO in the preview (for example GCA0KAX / 4. CITO in Guntramsdorf) as example for the behavior
image.png.5aa06071faccc2c587a25fbbecac481a.png

If I download the PQ, it is missing in the gpx file:
image.png.b2d4562f740ff8f073a3986979dbf209.png

Here the PQs, I have this today:
AT_Events
https://www.geocaching.com/pocket/gcquery.aspx?guid=138703f0-9f4b-4c2d-9ed6-8191df02b5ba
https://www.geocaching.com/seek/nearest.aspx?pq=138703f0-9f4b-4c2d-9ed6-8191df02b5ba

UK_London Events
https://www.geocaching.com/pocket/gcquery.aspx?guid=fdb29144-96c1-4e26-8dbf-84710155ba31
https://www.geocaching.com/seek/nearest.aspx?pq=fdb29144-96c1-4e26-8dbf-84710155ba31

Both are restricted to the state, so I do not have wrong countries.
I can also see this with CCE for example: GC8K17Q
In the London PQ, I miss a Mega: GC9MAXX in Austria there are no Megas published, so I can not verify.
Other types I did not check, but maybe only normal Events are in the PQs gpx files

Link to comment

When I downloaded PQs at home in GSAK, there I had problems, downloading 4 PQs today in the afternoon, when I came back from a business trip, Most are from 17.10.2022 in the evening (around 20:45 CEST)

Status 404, URL not found: https://api.Groundspeak.com/v1.0/lists/PQV8TNY/geocaches/zipped Höflein 17.10.
https://www.geocaching.com/seek/nearest.aspx?pq=d41ba73c-4047-4896-b7cd-15708f44d4e6
Status 404, URL not found: https://api.Groundspeak.com/v1.0/lists/PQVFXNE/geocaches/zipped Wels 17.10.
https://www.geocaching.com/seek/nearest.aspx?pq=87c939d1-1a6a-4ad1-bc50-1cb437877f1b
Status 404, URL not found: https://api.Groundspeak.com/v1.0/lists/PQVFN76/geocaches/zipped Leoben 17.10.
https://www.geocaching.com/seek/nearest.aspx?pq=87235bea-4a13-4bb6-9047-4ed5143aa6a2
Status 404, URL not found: https://api.Groundspeak.com/v1.0/lists/PQVE98H/geocaches/zipped Vorarlberg SW 17.10.
https://www.geocaching.com/seek/nearest.aspx?pq=96737337-8428-47c6-aa93-6a43cf32b7d5

If I import the downloaded gpx everything is fine. Now they are not available anymore on the website,
image.png.8dce7c6f170f588e891ad453e4211867.png
It is still available for download at the moment (20:25 CEST)
image.png.3f602e3577f7adda5d0379ef3ab7f118.png

It is not clear for me, why these 4 are not working, while 2 other not rerun PQs are still downloadable:
image.png.fbc4f6bbbc08fa5f63a6e075d5cb3802.png
https://www.geocaching.com/pocket/downloadpq.ashx?g=3ece0454-2a90-4224-b244-7f8a8daf0aa2&src=web

https://www.geocaching.com/pocket/downloadpq.ashx?g=30a4b9f1-c39e-41c6-818c-094c86b5d601&src=web
 

also some PQs on 18.10. not rerun again are working
image.png.1340ffb6c2e0fc4a83c9923d9eb2dc28.png
https://www.geocaching.com/pocket/downloadpq.ashx?g=8a54f7e4-e08b-4250-a5f7-a1325e49e19a&src=web
https://www.geocaching.com/pocket/downloadpq.ashx?g=61e68678-a57e-48af-abfb-c88c496d68ca&src=web

The evening ones on 18.10. were lost during migration period as @Bl4ckH4wkGER wrote some days ago. So at least, the 4 PQs  from stated should be working, since not in the migration period, but a day before and other PQs a few hours before or after are still downloadable. Maybe there is some other issue here also.

Link to comment
6 minutes ago, The Fearsome Four said:

I see @6foot3 posted it a couple of times but I didn't see an answer. The sort feature is no longer functional for PQ created from a bookmark list or from a filtered search

 

Here is my original post where I acknowledged that it was seen and that a fix is in the works: 

 

Here is another post from me 3h ago that we are aiming to resolve it before the weekend:

 

 

Link to comment

@DaTechniker

Thanks for the additional reports. 

 

We had an earlier report of missing CCE events by @baer2006. As part of that fix we also looked at all the other Event types and have confirmed that they will be included appropriately once the fix is live.

 

 

Unfortunately, I have a hard time following your second write-up.

 

If I understand you correctly, the PQs number 16 to 19 ran on October 17. They were available at one point and you downloaded them and imported them but now you're saying that they're no longer available, when they should be available for another 3 days.

 

If those PQs were ones that were scheduled in advance and part of the nightly runs, then I agree that they should have been duplicated appropriately. If they were manual on-the-fly PQ runs, those may have not been duplicated appropriately as the other examples we re-ran for you.

 

It's not scalable for us to track down individual PQs for individual players. Instead it's more effective if we can focus on larger patterns that effect all players.

 

Hence I propose the following: 

  • Wait to re-run any PQs until I have shared all the bugs that have been fixed to make sure you get the most complete data.
  • If the problem PQs were single-run PQs and may have gotten lost, please rerun them. If they still don't work properly, please let us know.
  • If the problem PQs were scheduled PQs and will rerun on Monday, October 24, let's wait for them to rerun and again, please let me know if there are still issues with them.

 

 

Bug list pending QA and hotfix:

  • Pocket query preview does not work properly, including sorting
  • PQs only include regular Events, bot none of the other ones
  • PQs that have the "Found in the last 7 days" filter checked remain empty
  • Wrong order of <author> element makes import into Garmin MapSource fail
  • New PQs for caches along a route don't run


Again, I will let you all know once those are deployed. Thank you for your patience.

Link to comment
3 minutes ago, Bl4ckH4wkGER said:

Unfortunately, I have a hard time following your second write-up.

 

If I understand you correctly, the PQs number 16 to 19 ran on October 17. They were available at one point and you downloaded them and imported them but now you're saying that they're no longer available, when they should be available for another 3 days.

 

If those PQs were ones that were scheduled in advance and part of the nightly runs, then I agree that they should have been duplicated appropriately. If they were manual on-the-fly PQ runs, those may have not been duplicated appropriately as the other examples we re-ran for you.

 

It's not scalable for us to track down individual PQs for individual players. Instead it's more effective if we can focus on larger patterns that effect all players

I know it was a lot of information. I tried to prepare it for a support process.
We had the issue with the PQs at the 18.10  this is kwown.


The problems I wrote are a day before at 17.10.. It is clear, you can not track down all my PQs. This would also not be necessary, since I have the data. I only saw when updating my caches via GSAK, and I read the other post running also later on. My idea had been, that some 2nd level support may help finding some root causes, especially, since some data is lost during a day, that is not in the comunicated timeframe for the migration in this thread.

But for your question:
PQ 14&15(17.10.) and 20&21(18.10) are working, these are regular once a week running PQs
PQ 16-19 (17.10.)which is exactly between the other two is not available anymore for download, but still in the list PQ. These are saved an adopted when running manually, because of 1000 cache limit per PQ, so the range is reconfigured at each run. On 18.10. there is a twice a weekly run PQ filtered for 7 days, this one is also missing in the download list, I got some strange mail about this also.

Manual PQ on 19.10. were rerun by you, because they were not even available a few minutes after they ran from the notification mail on the 18.10. 
All other following days, the manual PQs were run and files could be downloaded from website and GSAK today.

So I see a non explainable behavior for 17.10. in the evening (CEST). Due to your reply, I did some further tests and found this behavior:
All samples of regular run PQs before 18.10. I tried can be downloaded, the all have this setting active: "Run every week on days checked" (her PQ 14 of my example)
image.png.e6a1f3c02df867be78a75861872e8155.png

All PQs with the setting "uncheck after the query runs" I tried, that were run before incl. 17.10.2022 (here PQ 16 of my examples)
image.png.0357f75a7eab7b8f34f5db6c34f97a20.png

For me it looks like, the migration process itself was not run correctly. It looks like the database entries were migrated, but the corresponding download files got lost during migration to the new backend and file server. Maybe some engineer can do something with this information.

Thanks for the list of known bugs here. It got a little unclear and confusing in this thread, so it looked like I missed some information.

Link to comment

@DaTechniker

Thank you for the follow-up and the additional detail.

I will follow up with our engineers to check about the PQs that were scheduled with "uncheck the day of the week after the query runs" checked. I'll see whether we can either migrate missing data or even if not that we make sure that such queries run as expected going forward.

 

For general context, with most PQs running once a week, we always had to pre-populate a whole week before making the release switch. While I expected some queries to get dropped in the process, I want to make sure that once the switchover week is done, we have things running as expect again once all PQs would naturally run in the new service "for their first real run" :) 


Thank you for your help!

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Followers 7
×
×
  • Create New...