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.
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:
This:
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(https://github.com/thin-edge/thin-edge.io/pull/2600), now the aim would be to do something similar withc8y_mapper_extand its operation handling.Describe alternatives you've considered
Additional context