Description
Is your refactoring request related to a problem? Please describe.
As originally described in the Further Comments section in the PR about using the File Transfer Service for log and config operations, the current architecture of the C8y mapper actor adds unnecessary complexity to the operation handling code, by:
- spreading the execution of the operation between many different functions, making it harder to locally reason about the code
- needing additional variables to keep the state necessary for handling of the operations, read by the different functions that run at different stages of the operation lifecycle
This:
- introduces additional friction when making changes to operation handling, because one needs to update multiple functions that each handles a part of the operation's lifecycle, and the signature of the data being passed between these functions, frequently adding additional fields
- mixes levels of abstraction: the actor needs to be aware of the different operations so that it can invoke correct functions to continue handling them
It concerns mainly the interaction between downloader and uploader actors, where every time we need to download/upload from within the operation, we need to send the request and return, in order not to block handling of other things.
Describe the solution you'd like
The preferred solution would be to handle the entirety of an operation in a module dedicated to that operation, without returning, saving state, and relying on other parts of the code to continue the execution. We should be able to run the future that handles the operation concurrently, as that's what async/await should allow.
This was already done for c8y_firmware_manager (#2600), now the aim would be to do something similar with c8y_mapper_ext and its operation handling.
Describe alternatives you've considered
Additional context