Alan King

Linking #4675 as well, which is linked to that issue. Thanks!

Also, https://github.com/irods/irods/pull/6407 may fix this issue as well.

To be clear, connections are cleaned up by the server after the TCP connection times out, but this just handles the client-initiated terminations more gracefully.

Davrods does not hit the actual put API, but performs an open/write/close. Please see this comment for details on which dynamic PEPs are engaged in the put operation: https://github.com/UtrechtUniversity/davrods/issues/18#issuecomment-564083159 The...

Since this is scoped for 4.3.1 as a Documentation exercise, I think the task is complete. Please close if true, @korydraughn. Thanks!

Yes, it seems the object is stuck in the locked state, meaning, the replica which was created was never finalized. Were there any messages logged around the touch operation itself?...

In the first set of log outputs you provided, the "request_release_version" has a value of "rods4.3.0": ```json { "log_category": "legacy", "log_facility": "local0", "log_level": "info", "log_message": "[rsDataObjUnlink_impl:334] - [HIERARCHY_ERROR: no valid...

Also, please see the Troubleshooting docs for how to remove the offending data object(s): https://docs.irods.org/4.3.0/system_overview/troubleshooting/#data-object-stuck-in-locked-or-intermediate-status

Right, the 4.2.11 versioning is a red herring. Sorry about that. In addition to what @JustinKyleJames linked, this is probably directly related to this issue: https://github.com/irods/irods/issues/6154 So, this is a...

Ah, the documentation still hasn't been fixed. The replica statuses are actually set by the integer values used in the database when using `iadmin modrepl`. In this case, you will...