Possible access/indexing issue affecting Madrid municipal census records in Full-Text Search

Fernando22143

Hello,

I am posting this here after being referred by FamilySearch EU Support.

I originally contacted eu_support@familysearch.org regarding what appears to be a possible technical or collections-access issue affecting some Madrid census records. Their latest response advised me to ask about it here because “this is where the record specialists pay attention to records and record needs.”

I would therefore like to describe the behavior as clearly as possible to determine whether:

• this is an intentional permissions structure,
• a known indexing/access issue,
• or possibly a technical problem related to Full-Text Search and historical collections.

What I observed is the following:

In some Madrid historical census collections, a municipal census record appears to exist simultaneously in two linked forms:

1. as the original municipal census historical record/image,
2. and as an additional census/index layer associated with Full-Text Search.

While both layers were present, I was able to access and view the original historical image normally.

However, when the secondary census/index layer later disappeared or became unavailable, the underlying municipal census image also became inaccessible, even though it appeared to be exactly the same historical document that I had previously viewed directly.

From the user perspective, this creates the impression that access permissions for the original municipal census image may somehow depend on the existence of the secondary indexed census layer.

What makes this confusing is that:

• the historical image itself had previously been viewable,
• the restriction only appeared after the indexed layer changed or disappeared,
• and the behavior does not resemble a normal image restriction message alone.

I am not asking for genealogy research assistance, but rather trying to understand whether anyone familiar with these collections or with Full-Text Search architecture has encountered similar behavior.

Has anyone seen this happen with Madrid census collections or other Spanish collections?

Any clarification would be greatly appreciated.

Fernando22143

Thank you very much for your replies and for taking the time to investigate this issue.

After revisiting the Madrid census collections and attempting to reproduce the problem again with a clean Municipal Census/Census record, I have unfortunately realized that I can no longer reproduce the access issue I described.

It appears that whatever behavior or restriction I previously encountered has either since been corrected or was related to a temporary issue that is no longer present. After testing again, removing the census layer still allows normal attachment and viewing of the historical document.

Therefore, I would like to sincerely apologize to the Community for any confusion and for taking up your time investigating a problem that I am currently unable to replicate.

I especially appreciate the willingness of users here to look into the matter and request examples in order to help properly analyze it.

Thank you again for your patience and assistance.

SerraNola

@Fernando22143

Thank you for reaching out, and we're glad the access issue resolved itself — but your questions are still worth addressing for future reference for all of our Community members.

You're right that there are two layers involved when you view an image: the original archived image itself, and a searchable index built on top of it. Normally these two work together seamlessly. However, occasionally, we experience a bug related to how our image permissions and index/Full-Text layers interact in the backend. It is resolved when the two layers get back in sync. I can also confirm that the Madrid census collections are among those known to have had previous permission issues.

If this happens again, please reply here with the film numbers involved and we'll make sure your report is routed to the appropriate records team for resolution.

Thanks also for a very comprehensive review of the issue!

SerraNola

@Fernando22143 

Thank you for the links — they were very helpful in tracking down what's happening.

After investigating, I believe it is a different error, but also one that we’ve seen before. It appears that all—or nearly all, of the images in this collection have a second indexing on top of the first one. In December, 2023 it was indexed with the record type, “Census”. In September of 2024 it was indexed as “Municipal Census”. When a record type changes during an update, the system treats it as a mismatch and creates a duplicate index. Several other fields were also duplicated in the process, which produces confusion in search results.

It seems the easiest user fix would be to delete the duplicates. However, deleting either duplicate index causes approximately half the records to lose access entirely — meaning those records become invisible to users. For example, on image 74 of the film, only the two siblings you mentioned remain visible, while all other individuals have disappeared from view even though they are still present in the underlying index.

I will show this record type duplication error and the behavior to engineering. I saw your post in Feedback and it has not yet received attention, so there will be no overlap.

We appreciate your patience, and thank you for providing the detail that made it possible to identify this issue.

MandyShaw1

@Fernando22143 please post example urls demonstrating both the 'working' and 'non-working' scenarios so that this Community can help you look into this. Thanks.

Áine.ní.Donnghaile

@Fernando22143
Is this the collection?
Spain, Madrid, Municipal Census Records, 1910-1945
https://www.familysearch.org/en/search/collection/5000004

Áine.ní.Donnghaile

@Fernando22143
I'm glad it's working again for you. There are often short-term problems with any website.

Áine.ní.Donnghaile

@SerraNola
Perhaps related to the previous issues?

When I searched for the collection in the catalog, no results were returned.
It does appear when searching from the main Record Search page

and from the Spain Record Finder in the Wiki.

Thanks.

SerraNola

Áine, thanks for bringing this up. There is no problem accessing at all from Collections or Images, but no trace of it in the catalog. I don't think there's any connection to the previous issue, but it is a problem to be addressed with our catalog team.

Áine.ní.Donnghaile

Thanks, SerraNola.

Fernando22143

Unfortunately, I need to reopen this issue because the behavior has now returned, and additional inconsistencies have appeared.

After the previous discussion, I also contacted EU FamilySearch Support directly. Support informed me that the issue appeared technical in nature, submitted Feedback on my behalf for engineer review, and advised me to continue documenting the behavior here in Community as well.

Thank you again to @SerraNola for previously pointing me toward the synchronization /index-layer explanation, as the new behavior now seems consistent with that diagnosis.

After my previous follow-up, the image became accessible again and I was able to continue working with the household record. However, while attempting to standardize duplicated Census/Municipal Census entries for two siblings in the same household, the following behavior occurred:

• one sibling still retains a working “Municipal Census” event,
• for the other sibling, the Census/Municipal Census event option disappeared entirely,
• attempting to create or link a Census/Municipal Census event produced “Something unexpected happened,”
• and afterwards the image became inaccessible again.

Image Group Number:

https://www.familysearch.org/en/records/images/search-results?imageGroupNumbers=108283763

Image involved:
https://www.familysearch.org/ark:/61903/3:1:3QHJ-7Q3F-KL9V

Indexed source:
https://www.familysearch.org/ark:/61903/1:1:6L1C-54HX

Given the explanation previously provided regarding synchronization problems between image permissions and Full-Text/index layers, this now appears consistent with that type of backend desynchronization issue.

I can also provide screenshots if useful.

—

Additional information that may help isolate the issue:

Thanks to @Áine.ní.Donnghaile for pointing out the collection hint, I discovered that the image is still accessible if reached through the collection catalog/search path, even while the normal hint/preview workflow fails.

Collection:
Spain, Madrid, Municipal Census Records, 1910–1945
https://www.familysearch.org/en/search/collection/5000004

What currently happens is:

• if I access the record through the FamilySearch hint/preview workflow, the preview may fail or produce errors,
• however, if I manually enter the collection, search for the household, and open the image from there, the image can still be viewed normally.

For example, I was able to recover access by:

1. opening the Madrid Municipal Census collection,
2. searching for the Tomasety/Pastor household,
3. opening the “Padrones: Universidad. Municipal Census 1910” result directly from the collection search results.

This seems to further support the earlier explanation regarding synchronization problems between image permissions and Full-Text/index layers, because the same image behaves differently depending on the access route used.

Fernando22143

@SerraNola

Thank you very much for taking the time to investigate this issue so thoroughly and for explaining what was actually happening behind the scenes.

Your explanation makes perfect sense now and clarifies the confusing behavior I was observing between the duplicate “Census” and “Municipal Census” layers, the disappearing records, and the intermittent access problems.

I also greatly appreciate you confirming that this is a genuine duplication/indexing issue and for forwarding the matter to engineering. I know this likely required significant time to trace and reproduce, especially given how inconsistent the behavior appeared from the user side.

Thank you again as well for your patience throughout the discussion and for helping identify the real source of the problem.