I think if EPC does little without a storage_manager or network_manager, and set_storage_manager and set_network_manager will only be ever called once in EPC's lifecycle, maybe you should initialize them within the init, so you can guarantee they are always there and not optional (thus removing all the trailing ! anytime you reference one). I realize this complicates the shared singleton setup, but you can comment that out for now until we implement what network_manager and storage_manager look like.

public init(network_manager: NetworkManager, storage_manager: StorageManager) {
    self.network_manager = network_manager
    self.storage_manager = storage_manager

    EVENTGATE_URI = "https://intake-analytics.wikimedia.org/v1/events"
    CONFIG_URI = "https://meta.wikimedia.org/w/api.php?action=streamconfigs&format=json"
    ISO8601_FORMATTER = ISO8601DateFormatter()
    ENABLED = true
        
    recall_buffer()
    configure()
}

then these properties can be non-optional constants:

private let network_manager: NetworkManager
private let storage_manager: StorageManager

Actually this piece will need some thread-safety too. For this simple serial queue approach you can try queue.sync, that pauses the current thread execution while queue goes off and pulls the value and returns it back to the original thread that needs it. A pattern I've noticed in this codebase is to create a bunch of helper methods for getting and setting to these data structures. That buries all the queue.async and queue.sync calls and cleans up the code. It was a bit long to give an example here so I tried it in this commit.

Also as I'm looking at this I think we might need thread safety when accessing or setting the streamConfigurations and streamCopy properties as well 😕 so I'll leave that for you. The reason being they are referenced in log(...), which I envision will get called from multiple threads as we pepper them throughout our codebase, so we want to make sure these properties stay intact.

Thanks! Hopefully I did it right in the upcoming commit

You'll be losing any previous values that were in streamCopy with this vs. how the old code worked. Seems like that's what you're wanting anyways, but just a heads up in case you expect setStreamConfig to be called more than once.

That's a good point! As it is we're good since the stream configs are downloaded & processed only once, but once we figure out how to approach multiple stream configs (if at all) in the BUOD <> Apps sync we'll know if this needs to be modified to do, like, a merge operation.

You probably want let jsonString = try copies.toPrettyPrintJSONString() on line 348 below now.

Can you also reference this method instead of using streamConfigurations directly in the configure() method and inSample(stream:) methods?