Data loss in accessioning module- possible result of slow connection?

8 views
Skip to first unread message

Louise Smith

unread,
Dec 11, 2025, 4:01:05 PM12/11/25
to archivesspac...@lyrasislists.org

Hi all,

At the archive where I work, we are seeing some odd behavior in the accessioning module, and to find out whether anyone has run into something similar (for context, we are running ArchivesSpace v4.1.0, hosted in AWS):

On WFH days, staff connect from home through VPN. The person who is seeing the problem is our primary user in the accessioning module and has permission to create and edit accessions.

The first symptom we noticed was what looked like data loss. On December 5, she opened an existing accession in order to mark it as processed in the collection management record. When she saved, the “processed” status did not stick, and all of the component links on that accession disappeared. She did not touch the component links subrecord during that edit, so it was a surprise to see those relationships drop out.

Since then, while working remotely with VPN on and a stable home internet connection, she has had recurring trouble getting the accessioning module to load and behave normally. In particular, the screen will hang or become extremely slow when she tries to open or edit subrecords such as Related Resources, Component Links, and Agents. In some cases, other fields, such as the identifier field, simply will not accept new input at all. 

We are in the process of doing more controlled testing (different browsers, a second laptop, etc.), but before we go too far down that path I wanted to ask:

Has anyone on this list, especially those running v4.1.0, seen similar behavior in the accessioning module where:

  • editing one subrecord appears to cause data in another subrecord (for example, component links) to disappear on save, or

  • subrecords like Related Resources, Component Links, or Agents become very slow or effectively uneditable when staff are working remotely over VPN or a higher latency connection?

If so, were there particular configuration settings, timeouts, or log messages that helped you track it down? And are there any known issues in v4.1.0 that sound close to this pattern that we should be aware of? 

Thanks,
Louise



Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

Reply all
Reply to author
Forward
0 new messages