steve8x8 / geotoad

Geocaching query tool written in Ruby
https://buymeacoffee.com/steve8x8
Other
28 stars 8 forks source link

Caches without logs - GCN17F returns error when trying to access logbook #258

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Reported by "Susi Sorglos" via private communication.

What steps will reproduce the problem?
1. Run a "wid" query for "GCN17F".
2. Get an "ERROR: Check your login data..."

What version of the product are you using? On what operating system?
- probably doesn't matter at all since the problem is located on the server 
(see below).

Please provide any additional information below.
- If one opens the page for cache GCN17F (e.g. via coord.info/gcn17f) the whole 
logbook part (including the stats) is completely absent.
- One may view the "print without logs" page, while "5 logs" and "10 logs" 
result in "error 500" pages. (redirect to 
"/error/error.aspx?aspxerrorpath=/seek/cdpf.aspx")
- Replacing the "cdpf.aspx" part of the "no logs print" page URL with 
"cache_logbook.aspx" one gets a page with zero logs entries. Not even a 
"published" log...

This is definitely a defect (in error handling), but should only rarely show 
up, priority set to "low".

Original issue reported on code.google.com by Steve8x8 on 3 Nov 2012 at 3:25

GoogleCodeExporter commented 9 years ago
I was able to temporarily "tame" this cache (by writing a note, running GeoToad 
- which showed a single log entry, and deleting the log again).
This means that for some reason the whole series of log entries got lost for 
this particular cache, setting a counter to zero, and confusing the server 
routines.

Please DO NOT WRITE ANY LOGS for this particular cache as it's a welcome test 
case.

If you have to work around it (or a similar one):
- Write the GCxxxx code to a text file
- Use GeoToad 3.17.0 or later (from the development series), and add an option 
to your command line "-E skipcache=filename" - the username can be chosen 
randomly, and filename should be the name/path to the text file of the previous 
step
- This should skip the cache (by faking it as "found") and let you proceed.

Again, please don't write log entries for GCN17F, thank you.

Original comment by Steve8x8 on 3 Nov 2012 at 3:34

GoogleCodeExporter commented 9 years ago
Quick hack to handle the "500" case by trying to use the "no logs" page instead.

This isn't foolproof yet (what if there's a 500 error triggered by another 
cause?), and hasn't been checked against bad cookies, wrong login data, etc.
At least it makes GCN17F accessible again.

To be applied from the geotoad "root" using "patch -p1", as always.

Original comment by Steve8x8 on 3 Nov 2012 at 3:50

Attachments:

GoogleCodeExporter commented 9 years ago
Another patch trying to match this case more strictly.
I'm not sure yet how to handle other 500 errors - just return an empty page?

Original comment by Steve8x8 on 3 Nov 2012 at 4:01

Attachments:

GoogleCodeExporter commented 9 years ago
Yet another version, addressing the cdpf issue by removing the log request 
(&lc=nn), and returning an empty string otherwise.

Original comment by Steve8x8 on 3 Nov 2012 at 6:05

Attachments:

GoogleCodeExporter commented 9 years ago
Merged into branch - please test. I hope the fix won't affect other error 
handling (expired cookies, wrong passwords, etc.) - will do some testing myself 
later

Original comment by Steve8x8 on 5 Nov 2012 at 11:12

GoogleCodeExporter commented 9 years ago
Some background for this particular cache:

GCN17F has been created back in 2005 when there were no reviewer "Publish" logs 
yet (at least that's what the hamsters say), and obviously nobody has ever 
found this cache. Actually nobody knows whether it's still there. (I will ask 
the owner.)

I know that there are a few caches in extraordinary locations (polar areas, 
Siberia, ocean depths) which might never have been found, but this is the first 
one which turned up in a GeoToad search. You may estimate when the next similar 
incident happens... Nevertheless, it's good to have reviewed the http 
redirection handling, so this fix will go into trunk soon.

If you find similar caches without logs, please drop me a note.

Original comment by Steve8x8 on 10 Nov 2012 at 3:38

GoogleCodeExporter commented 9 years ago
Not having found any side-effects, I merged the patch (which also fixes a 
misleading debug message if a redirect goes to a https page) into trunk.

Original comment by Steve8x8 on 21 Nov 2012 at 10:46

GoogleCodeExporter commented 9 years ago
In released version 3.16.3

Original comment by Steve8x8 on 30 Dec 2012 at 2:55