-
Notifications
You must be signed in to change notification settings - Fork 12
Re-think the logger API and internal propagation between shared core and SDK #465
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This is a final example of the new logs:
The |
Improved formatting
|
Just curious
This appears to be showing the resolving of an awakeable and the value it is being resolved with? What else is going to be shown this way? Like, ctx.serviceClient calls and their payload? Can there be a way to opt-out of exposing the values/payloads in logs if they could be sensitive? |
This is not from the SDK, this is a manual console log statement in the code: https://github.com/restatedev/sdk-typescript/blob/main/packages/restate-sdk-examples/src/greeter.ts#L20 |
Ahh! All good then So what's this about:
That's like 55 years lol Accidental overwrite, but the reply from @slinkydeveloper is:
|
This one is now ready to merge, pending re-generating the VM and fixing the conflict |
…h the logger facade. Introduce a Logger interface, extending the Console interface, that will be used within the sdk by the shared core.
…are correctly propagated and they use the context aware logger created when the invocation starts.
82da95c
to
85638a0
Compare
85638a0
to
2fba236
Compare
Fix #457.
This API brings API changes, mostly around naming, to the logger internal api. It also renames a publicly exposed logger interface, now named
LoggerTransport
(reflecting names used in other known JS libraries).