|T344206 Special:MathStatus exception error on Wikifunctions
|T342865 Post-creation work for wikifunctionswiki
|T289316 Prepare and check storage layer for Wikifunctions.org (new public content wiki)
|T275945 Create Wikifunctions.org
|T299176 Phase Theta – Root task
|T299598 Add security limits to the Wikifunctions system to maintain stability and integrity of the content
|T285312 Enable Logging in Backend Services
|T290700 Use a Proper Logging Module in Orchestrator
The service-runner framework provides a logger object that uses bunyan, a proper logging library. The problem is how to make this logger object available to code throughout the orchestrator.
One approach would be to pass around a context object for all request-scoped values and services, including a logger. This would mean changing the signature of most functions in the orchestrator, making it a pretty invasive and involved change.
I propose we add continuation-local storage for this. We'd have a request-local namespace that gets created in initAndLogRequest, and store / retrieve the logger object from there.
@ori Thank you for providing options! I agree with the continuation-local storage suggestion.
I'll note that we do have an object which is passed around to every function in the orchestrator (helpfully called invariants), so we could put a logger there, but it's an unpleasant solution (and also won't let us log anything in imported functions, e.g. from function-schemata).
Unfortunately continuation-local-storage and its more modern counterpart, AsyncLocalStorage come with a substantial performance cost, particularly for workloads with a lot of async/await calls. I don't think we can afford the performance penalty.
I went for a much simpler global logger object approach in I7126a1d49. I think it's simple enough that if it becomes cheaper to annotate the logger object with additional tags to identify the current request context, we could add it there quite easily.