Platform: iNaturalist website
App version number, if a mobile app issue:
Browser, if a website issue: Chrome
URLs (aka web addresses) of any relevant observations or pages:
https://www.inaturalist.org/observations/364040418
Screenshots of what you are seeing:
Description of problem:
Step 1: Scrolling through Needs ID, I came across an observation with no ID’s, yet it was labeled as Bullock’s Oriole. How is this possible? https://www.inaturalist.org/observations/364040418
Someone has just added a second ID and it is RG already. Possibly needed to force a reindex ?
But your screenshot shows the previous ID was not visible. ID is / was from 22 May 2026.
I checked on our test server, which showed data from last Saturday, and saw the same thing. I faved and unfaved the observation and one ID appeared. So yeah, something was glitched out and a reindex fixed it, but I’m not sure how it got into this state.
Odd.
I’m thinking when an observer uploads an observation, they might originally select or import it with a species designation (like Bullock’s Oriole). If they (or a third-party app) subsequently delete or withdraw that identification, the observation page accurately shows zero IDs in the Activity section.
However, the main text header at the top and the search index database can temporarily get “stuck” caching the deleted name. It then retains the label until a new database reindexing event occurs.
I cannot find where, but I know occasionally when observations are imported through third-party photo-sharing tools, api integrations, or mass uploaders, a synchronization error can cause the taxon field metadata to fill with a specific species string on the backend while failing to generate the actual user identification card on the frontend layout.
Edit: everything above this is irrelevant
Ok, it gets weirder. In order to troubleshoot I added a species level ID, my intention was to force a reindex and then delete my ID to see if it would have the same result.
However, after making my ID the screen froze and then my the screen glitchingly pushed the ID down and then an ID from 2 months ago showed up. I can confirm my screen looked exactly like the screenshot sent earlier before I did this. This has happened with ID’s on personal count related stuff.
So the solution is that the observation did actually have an identification added two months ago, but the database connection for that specific card was stuck in a corrupted state or hidden behind an asymmetric loading delay. Because the page failed to render the physical card of the frontend layout, the activity log appeared blank to everyone looking at it. As the layout re-synced with the master server database, the server pulled the true, historical timeline. It corrected the order by instantly rendering the old 2-month-old ID card exactly where it belonged chronologically—right at the top—which must’ve created the weird visual of my ID getting pushed lower.
If we could see the history of an observation this never would’ve been a problem.
See my specific post. I checked the exact time I made the ID (ten minutes ago), and your post was six minutes ago. So, my ID was before you would’ve faved it. By any chance, were you able to see my ID as you did this like @DianaStuder, or no? Both solutions probably simultaneously did the same thing and didn’t have any relation to each other.
As I said, I did my testing on our test server, not the production server that the public uses. So it was not affected by any other interactions but mine.
That test server’s data comes from a backup made this past Saturday, so as far as I can tell the observation was in this state since at least then.
I see, my apologies. I read it as I did a test on my server.
Interesting.
All good, I could have written that more clearly.
