The OpenScience Laboratory The Open University

iSpot Forum

10000+ agreements?

" By DonCatchmentRT
Location Sprotbrough
Observed 24 May 2017
Added 13 July 2017
Identifications 1
Agreements 10787
Comments 0
Description Small brown spider. Darker brown body. Less than a centimetre in length."
(Copied from

I’ve seen similar in other obs too. If you open the post there’s a realistic number of agreements. Until yesterday iSpot was having trouble counting up to 1 in identifications; now a problem with agreements. What next? A negative number of comments? That, at least, would be an improvement over a number of negative comments!


Lets hope it is something easily fixed. You should note it disappeared if you agreed to the name (thus Likely ID) or if a name not matching the dictionary name.

Yes, I guess it should be easily fixed. As an ex computer professional I am more worried about the standard of testing regime that allowed bugs like these to get through and about the other bugs that have got through that we’ve not spotted yet. I’ve always subscribed to the notion that the best way to know that a project is bug-free is never to find the first bug!

10787 !

That’s a good un, here’s two for posterity - I love it! though it’s not very funny!

And lots in the southern African community too:

This is the situation at of 20h10 +2h on 13 July:
. for page 1:
Moth 10787 agreements (Likely ID = null, 1 ID – correct (is not likely)
Rainbow skink 0 IDs – likely ID = Rainbow Skink (Trachylepis margaritifer) - not correct!
Buxton’s Hairstreak female 10787 agreements
Broad-leaved leonotis 10787 agreements

It seems that our our little caching issue that was fixed yesterday ( might be a little bigger than given credit for.

0 bugs fixed this week!

but it reverts to 10787 if you remove your agreement.

Anyone figure out why 10787? (I dont know the total, but the southern Africa had at 1 June: 495 954 agreements, so it is not that)

German Wallpaper?
Or Genram postcode


Postal code: Berlin 10787
NCKAP1 NCK associated protein 1 [ Homo sapiens (human) ] (Gene #10787)
Escherichia coli (Migula 1895) Castellani and Chalmers 1919 DSM No.: 10787
Prohibitin Antibody - Rabbit Polyclonal| Catalog number: 10787-1-AP

Cannot find anything associated with programming. Must just be a random number associated with the cache.

I assume that the logic implemented is something like

if there are agreements
    set count to 0
    for each agreement
          add 1 to count

rather than

set count to 0
if there are agreements
     for each agreement
          add 1 to count

if count is on the stack it’s liable (depending on language semantics - some modern languages would run an initialiser on all scope variables on entry to the scope) to have a random value.

(The 6th button on the editing panel is what allowed me to enter indented text.

Dont be silly.
These are professional programmers. That error is something only naive novices would make, and then only once.
It is not even logical!
If that is the error, then heaven help iSpot.
But then there are at least 10 instances of page transitions not making any sense at all, so perhaps we do have someone without a grasp of logic involved in the programming.

But given the volume of LIST calls (user, community, project, dictionary, filters) surely the call is implemented when an agreement is made and not when loading the page. So the observation should have a field [agreements] and the value incremented by one when an agreement is made and by -1 when removed. I would wager that 10787 either is a “null” value or else another variable.
Note that if you add an agreement it becomes one, but if you remove the agreement it reverts to 10787, But not all observations with no agreements are 10787.
Currently on the sAfr LIST page 1 are 17 observations with 0 agreements, and 2 with 10787. There are no observations with 10787 agreements posted before 12 July (although I only checked a few pages).

This is part of a much bigger boo boo.

Look at the observations:

nothing else remarkable here ID = 1, Likely ID = 0, although agreements 10787

Note: the user has 4 plant badges, but the ID has not linked to the dictionary and the same user has no badges in this presumably “not group” - but the group is plants so this is a bug!.*** The scientific name used is valid (and spelling correct) but the common name is not in the dictionary, but iSpot did not link this to the dictionary (a bug2!).

the next observation:
has 1 ID, likely, with 5 agreements, but the list reports likely ID yes; IDs = 0 and agreements = 5.

There are 2 observations with a likely ID but IDs = 0.

All the weird data are within the period 8am to 2pm on 12 July. NO: only in ZA, in UK is much later into 13 July!

but I am willing to bet that the two bugs are connected. For these 10787: has no reputation has no reputation dictionary mislink and no reputation shown as a consequence has one badge, too few to invoke likely ID has no reputation has one badge, too few to invoke likely ID dictionary mislink and no reputation shown as a consequence

BUT is identified by a four badge (but not the poster 2 badge) but BUG3: no likely ID is invoked. (might it be something to do with “agg” species.) even though user has reputation in this group.

All the 10787 are associated with no reputations and thus no likely ID for the group (compounded by cases of a dictionary mislink and no group assigned). This suggests that where there is [-no likely ID-] for the group (or the group = unknown), then the agreement is assigned a value of 10787, or more likely, this situation is not anticipated in the programming and the value for agreement (and presumably many other counters in the observation) is not set and defaults to [empty] or [null], and is interpreted in List View as 10787.

another instance of this bug (Bug 2 - user has reputation in the group shown for the observation, but group in ID = nothing/other and no reputation given/in group, despite group observation staying same) here: JoP posted a non-linking ID, and got zero badges, despite her having a silver badge in plants.
So posting an ID that has not dictionary match results in a group “null” (or is it other organisms?) and no badges (or perhaps badges in other?) - this is not part of the 10787 complex as this is already the third ID, and Likely ID is witht he forth ID.
and here: - here no entry in dictionary so no group assigned so no likely ID: is a 10787 invoker.

BUG 1: counters not set if ID made but no Likely ID invoked
BUG 2: ID correct and in dictionary but not linking to the dictionary - why?
and BUG 3: IDs with no group (either linked to dictionary but problem, or not linked to dictionary) do not change the group of the observation and get no reputation (or reputation of “Other organisms” which is incorrect). Issue: mismatch of observation and ID group, probably due to no Likely ID. Suggestion: Obviously the observation has the group of the likely ID, and if there is no ID then that posted when the observation made. But for identifications that do not trigger a link to the dictionary and thus no group for the ID, the group in the ID box should be assigned to the observation group and not to the No Group (and NOT to “Other Organisms” - as 99% of users have no reputation in Other Group and so cannot invoke a Likely ID, perpetuating a cycle of mismatch).
If I agree with such an ID, it takes on the observation group, and my Agreement shows my repuation for that group, but the reputation of the original ID’er remains “No Group”
e.g. the user pf339 has 3 shroom badges on observation, but none on ID. If I agree, my 3 shroom badges show, but his ID remains no badges. FIX!

None of this explains why if you add an agreement it sets to 1, but if you remove it it sets to 10787. Unless removing an agreement invokes the entire faulty subroutine, and all the counters for all the IDs made are reset to null instead of 0. (Or lavatarguy is right after all!)

Federal Regulations and ‘Bob boos’

You are all wicked, do you hear - WICKED!
These are paid programmers, possibly experts in their field. Any ‘faults’ are due to the way computer handles the code, not the code itself; you understand?
Anyway there might, possibly, be Trump connection to 10787 it being “EXECUTIVE ORDER 10787 Transferring Jurisdiction Over Certain Lands” - I cannot find a Russian link yet. Give me $10787 and I’ll try

Do you accept bitcoin? :wink:

Watch it dejayM - this is a scam. A devious trick.

Clearly 10798 is null or empty, or alternatively a value that is supposed to be zero (0) - so you are being offered null bitcoin. I recommend refusing. Dont fall for the trap. also has the “magic number” of agreements.
This new iSpot is FUBARed programming of epic proportions.

But same problem: user has not enough reputation and cannot trigger a Likely ID, and so the “programming code fails” (to avoid being called wicked again)
and also (in 2nd ID) - BUG 2: ID in dictionary but iSpot does not link.

A virtual cornucopia of bugs in one observation. A debuggers heaven!!

No news? Do you think that they have stopped debugging?

I have noticed one of these 10787 agreement obs among my uploads, and both the ID and the single real agreement were made by people with high reputations. It does have a likely ID. However the list view still says “Identifications: 0.” It’s this one:

But it’s just had a second agreement, so now looks normal.

Correct: the ID, Agreements and Comments counts only update when an ID/Agreement or Comment is posted. There is no independent rechecking. So any ID/Agreement should fix the issue.

This is getting silly.Hundreds of unidentified Bugs on ISpot,perhaps we should stick to plants and birds.

1 Like