-
Notifications
You must be signed in to change notification settings - Fork 394
feat: setup new log system and record logs from LLD internal thread #4709
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
feat: setup new log system and record logs from LLD internal thread #4709
Conversation
🦋 Changeset detectedLatest commit: 5f0c8af The changes in this PR will be included in the next version bump. This PR includes changesets to release 49 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
The latest updates on your projects. Learn more about Vercel for Git ↗︎
3 Ignored Deployments
|
409f285
to
9c8f191
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great rework overall. some minor comments
65cadd0
to
3e6617e
Compare
Deployment failed with the following error:
|
63ba952
to
0f27710
Compare
Without breaking the behavior of the existing log function
The tracing helps keeping a context (for ex a `job id`) that is propagated to other logs, creating a tracing span
And enable filtering on logs displayed in the console for better debugging sessions
- Logs from the internal thread are forward to the main thread - The main thread records them, and can export them - If `VERBOSE` env var is set, filtered logs can be stdout from the main thread - Same from the renderer thread - Setup simple tracing system (context) on LLD
Avoiding any crash with try/catch when formatting
- and usage in LLM and LLD - also put LLM console logger mechanism in a class ConsoleLogger
Now manually JSON.stringify logs from the renderer thread before sending them to the main thread
The equivalent to the withDevice from a 1st version of the new device SDK
0f27710
to
1ab7bb2
Compare
Suspect IssuesThis pull request was deployed and Sentry observed the following issues:
Did you find this useful? React with a 👍 or 👎 |
`ledgerjs/logs`: * new `trace` and `LocalTracer` definitions, without breaking the behavior of the existing `log` function `hw-transport`, `hw-transport-node-hid-noevents`, `hw-transport-node-hid-singleton`, `react-native-hw-transport-ble`, `ledger-live-common` * Usage of new tracing system in some transports * The tracing helps keeping a context (for ex a `job id`) that is propagated to other logs, creating a (simple) tracing span Note on the "tracing": for now added a simple "context" that is propagated from `withDevice` to called functions, mainly from Transport. This is a preview of what could be done to have a real tracing system in the DeviceSDK Note: the optional `openTimeoutMs` on the different `open` function is necessary for legacy (used by one of the Transport), and will actually be used in the future. LLD: * Logs from the `internal` thread are forwarded to the `main` thread * The `main` thread records them, and can export them * on export, recorded logs from the `renderer` thread are sent to the `main` thread, and the `main` thread expand (not a merge, just pushed at the end) them with the logs it recorded from the `internal` thread * If `VERBOSE` env var is set, filtered logs can be stdout from the main thread * Same from the `renderer` thread * Setup simple tracing system (context) on LLD LLM: * Setup simple tracing system on LLM with context * If `VERBOSE` env var is set, filtered logs can be stdout from the main thread
`ledgerjs/logs`: * new `trace` and `LocalTracer` definitions, without breaking the behavior of the existing `log` function `hw-transport`, `hw-transport-node-hid-noevents`, `hw-transport-node-hid-singleton`, `react-native-hw-transport-ble`, `ledger-live-common` * Usage of new tracing system in some transports * The tracing helps keeping a context (for ex a `job id`) that is propagated to other logs, creating a (simple) tracing span Note on the "tracing": for now added a simple "context" that is propagated from `withDevice` to called functions, mainly from Transport. This is a preview of what could be done to have a real tracing system in the DeviceSDK Note: the optional `openTimeoutMs` on the different `open` function is necessary for legacy (used by one of the Transport), and will actually be used in the future. LLD: * Logs from the `internal` thread are forwarded to the `main` thread * The `main` thread records them, and can export them * on export, recorded logs from the `renderer` thread are sent to the `main` thread, and the `main` thread expand (not a merge, just pushed at the end) them with the logs it recorded from the `internal` thread * If `VERBOSE` env var is set, filtered logs can be stdout from the main thread * Same from the `renderer` thread * Setup simple tracing system (context) on LLD LLM: * Setup simple tracing system on LLM with context * If `VERBOSE` env var is set, filtered logs can be stdout from the main thread
📝 Description
ledgerjs/logs
trace
andLocalTracer
definitions, without breaking the behavior of the existinglog
functionhw-transport
,hw-transport-node-hid-noevents
,hw-transport-node-hid-singleton
,react-native-hw-transport-ble
,ledger-live-common
job id
) that is propagated to other logs, creating a (simple) tracing spanNote on the "tracing": for now added a simple "context" that is propagated from
withDevice
to called functions, mainly from Transport. This is a preview of what could be done to have a real tracing system in the DeviceSDKNote: the optional
openTimeoutMs
on the differentopen
function is necessary for legacy (used by one of the Transport), and will actually be used in another PR. Don't mind it during the code review. But it should only by passed to a couple of other functions, not directly used (in this PR).LLD:
internal
thread are forwarded to themain
threadmain
thread records them, and can export themrenderer
thread are sent to themain
thread, and themain
thread expand (not a merge, just pushed at the end) them with the logs it recorded from theinternal
threadVERBOSE
env var is set, filtered logs can be stdout from the main threadrenderer
threadUsage with
VERBOSE
:LLM:
VERBOSE
env var is set, filtered logs can be stdout from the main threadUsage with
VERBOSE
: in a.env
file, add (for ex)You will need to re-build fully the app so the new
.env
file is transfered.❓ Context
hw-transport
,hw-transport-node-hid-noevents
,hw-transport-node-hid-singleton
,react-native-hw-transport-ble
,ledger-live-common
,ledgerjs/logs
, LLM and LLD✅ Checklist
📸 Demo
LLD performance
Non-scientific manual measurements (on dev build): beginning of the fw update until the end of the fw transfer:
Measurements fw update transfer
With new log system (without
VERBOSE
):Without new log system:
-> no obvious performance decline
Exported logs from LLD
Example separation `renderer` and `internal` thread
Stdout debug logs on LLD with
VERBOSE
LLD logs on terminal
Stdout debug logs on LLM with
VERBOSE
LLM logs on terminal
🚀 Expectations to reach