The dataloader manager already generates an app_id/rec_id for the current session and passes it down to all dataloaders, which are then are then free to use it (or not!) when logging their data.
For example, the directory loader will use that centralized app_id, so that every file that gets logged end up in the same place.
RRD files are weird because they can contain arbitrary many streams, each of which might have their own app_id, so for now they never use the centralized app_id when we load them.
But sometimes it can be very useful to do so (basically any workflow that requires rr.log_file, so we need to expose a way to do it.
Related:
The dataloader manager already generates an app_id/rec_id for the current session and passes it down to all dataloaders, which are then are then free to use it (or not!) when logging their data.
For example, the directory loader will use that centralized app_id, so that every file that gets logged end up in the same place.
RRD files are weird because they can contain arbitrary many streams, each of which might have their own app_id, so for now they never use the centralized app_id when we load them.
But sometimes it can be very useful to do so (basically any workflow that requires
rr.log_file, so we need to expose a way to do it.Related: