Verify tag just stops when checking the just created tag

Question

When I tag a checker, I use the "verify tag" to check if the tag I have created is working  correctly.

If tagged correctly it shows on the outcome "OK" or if the challenge is not completed "Not ok"

If tagged wrong it shows on the outcome "Error"

My question is: What is the meaning if there is no outcome at all. It looks like the verify tag just stops?

Answer 1

That shouldn't happen. Cases I can imagine:

• 0 find logs on the challenge maybe. Note that the amount of logs in PGC is the relevant number, which has 24-36h delay.
• Interuption in the ajax call, but then it should work if you try again.
• It's brkoen for all tags due to some new bug (hard to imagine this though).

If the problem persists and none of the above seems to match, publish the tag so that I can test it as well.

Comments

ganja1447 , I have tagged GC3MYBV and GC3N2AJ, and left them disabled.
Simalar challenges are passing through the verification <okay>

---

I can not help if the tags or scripts are disabled. There has not been any permission override created in the system.

Got another guess though, maybe som JS error. If you return html = false and log = false. Does it work then? Otherwise, enable the script and tag so that I can run the verify myself.

---

On the other hand. I doubt it's JS errors since it doesn't really use the output. It only checks the ok flag.

---

They are now enabled

I had it twice before with a script from Target but then it was solved by using a scpt from Rikitan.

---

I found it meanwhile. Wrote a new command line utility. :)

user Alamogul needs a lot of memory (~340 MB), and then the whole process fails.

---

Can I leave the tags as they are?

---

I don't think the checker works. It returns false for everyone I have tested on (the 11 first except Alamogul).

---

From a fast glance at the source code, shouldn't the config argument be dayS, not day? I haven't checked other tags though.

---

Strange, the checker works on GC3MYCB and CB3N0BK of the same series

---

In case you missed it, read my last (now second last) comment. The gccodes you linked now proves my point.

---

Your wright one was the s was not there. I changed it but it still does not pass the checker

---

But now it returns the correct result, and works for everyone except Alamogul. Then I would say that it's good enough to be live. Then we will see if we will allow more memory in the future, or if we will require that some scripts gets optimized. Something we will look into in the future.

---

Ganja, on another one Alamogul come through on the verification as "Not ok" but all the cachers are OK

---

You are not really giving me information enough to answer you anything. I assume he does not fulfil it then?

---

We spent time enough on this subject for now, Thank you Ganja

---

I think Alamogul will be a problem on most checkers. I tried with the template script at uncommitted the local finds = PGC_GetFinds line
With the standard fields {'gccode', 'cache_name', 'visitdate', 'visitdate', 'country'} the scripts run out of memory
i 'country' i removed the memory usage is 249,344 kB  
But a user with 109.970 is an exception
The global #10 racer2814 with "only" 57804 finds uses 133,376 kB with the same script.
There is probibly no way to write that looks at all caches for the top 10
Racer2814 works fine on the script used in the GCcodes above "Generic streak checker" with a memory usage of 185,856 kB

---

Thank you for the additional information. Maybe we will raise the max memory for some users. Maybe it will end up with something like 128 MB + numFinds*0.01 MB, or something similar.

A more scientific approach than guessing would be needed though.

---

Thanks for the comment