Send baseMappingName when forwarding FullMeshRequest from TS to DS

[fm3]

Fixes a rare bug that occurs when the fullMesh.stl route is used on an editable mapping, but for an agglomerate ID that has not been edited.

In this case, the tracingstore (TS) redirects the request to the datastore (DS), and sends the mapping name so that the datastore can use the hdf5 mapping file to look up the segment ids for the agglomerate. The bug was that in this case, the editable mapping id was sent as mapping name, rather than the base mapping name, which corresponds to the hdf5 file.

While fixing this, I also restructured the logic of the MeshMappingHelper to more explicitly check the different combinations of the optional mappingName and tracingId.

Also added a few comments concerning baseMapping name in a few method signatures.

Steps to test:

• I tested with the render_animation worker job, which uses the fullMesh.stl route. The animation now correctly contained all selected meshes.

Issues:

• fixes fullMesh.stl fails for proofreading annotations for unchanged agglomerates #7885

---

• Updated changelog
• Removed dev-only changes like prints and application.conf edits
• Considered common edge cases
• Needs datastore update after deployment

[MichaelBuessemeyer]

The changes look good to me. I only found a very minor thing. You can decide whether my suggestion makes sense to apply.

I did not test as this is a rather complex scenario, but as you wrote already -> you already tested the changes :D

[MichaelBuessemeyer]

You have a duplication of this AgglomerateFileKey constructer (see lines 69ff.). Prior to these changes there was only one definition of the constructor and its result was stored in a val agglomerateFileKey.

=> A minor suggestion from my side would be to restore this and only have code that constructs the AgglomerateFileKey once :)

[fm3]

Thanks for the suggestion! Yes, I have already considered this. However, I ultimately decided against it, since the only ways that I saw to deduplicate this (without completely changing the logic again) would be either to construct the AgglomerateFileKey above the whole match statement, but that doesn’t seem right, since in most cases it won’t be used, or to extract it to another function, but that doesn’t seem right, because its call would look exactly the same as the direct constructor call.

So I tend to think in this case breaking the DRY-rule is less bad than the alternatives :)

[MichaelBuessemeyer]

Sure, sounds like a good reason to me 👍