are there any best practices to transfer the Custom-UI console.log statements to the Forge logs?
I suppose it doesn’t make sense to include external logging services in general.
I tried a simple approach: a resolver logger function which we called via invoke.
But I realized that the Forge-Log-output isn’t always in the order I make the calls.
I made 2 versions with the same result:
Synchronous call. Like
function forgeLog(logItem) {
invoke("logger", logItem);
}
Asynchronous call. Like
async function forgeLogAsync(logItem) {
let rc = await invoke("logger", logItem);
}
Hi @FranzBinder
Looks like you didn’t post the most intriguing part of your message.
You have one sync and one async example and both of them invoke your “logger” function. So what’s different between them from the logs order perspective?
Also, just to clarify, invoke always returns a Promise so even if your function is synchronous (“forgeLog” in your example) it’s in fact async: you just ignore the promise resolving .
invocation: a5b1b6a69fd7efc7 resolverBE.handler
INFO 21:45:12.156 a5b1b6a69fd7efc7 >>>LOGGER
INFO 21:45:12.157 a5b1b6a69fd7efc7 01
invocation: 5bbe4b6d463460a7 resolverBE.handler
INFO 21:45:12.279 5bbe4b6d463460a7 >>>LOGGER
INFO 21:45:12.279 5bbe4b6d463460a7 03
invocation: 77f038635fca2ada resolverBE.handler
invocation: 3d6f89e3b0be4e94 resolverBE.handler
INFO 21:45:12.514 77f038635fca2ada >>>LOGGER
INFO 21:45:12.514 77f038635fca2ada 02
INFO 21:45:12.529 3d6f89e3b0be4e94 >>>LOGGER
INFO 21:45:12.530 3d6f89e3b0be4e94 [ 99, 44, 66, { aaa: 'aaaaaa', bbb: 'bbbeee' } ]
invocation: 69359111ae834353 resolverBE.handler
INFO 21:45:12.646 69359111ae834353 >>>LOGGER
INFO 21:45:12.647 69359111ae834353 { name: 'John', place: 'here' }
The Forge Log output doesn’t appear in the same order. (The invovation time doesn’t fit to the order in Custom UI ).
The Forge Log output was captured from the forge tunnel.
Got it. Thanks for the example.
Yep, this all happens due to the asynchronicity of the bridge. Whenever you invoke something in your frontend, Custom UI gives you back a promise. If you want to have the same order, you need to wait for the promise to be resolved:
Thanks @Dmitrii , I already supposted that behaviour.
But waiting for all promises is no solution - I expect in a real application it would be time consuming.
I am intrigued by the question and I would like to understand a little bit better what is important to your investigation in regards of logging: performance or readability. Have you attempted investigating logs with the -- verbose --grouped options? This approach would help in terms of organized reading, although it will not resolve the ordering issue.
Adding both the verbose and grouped options shows log statements grouped by Invocation ID with the attached metadata
Hi @heinzen ,
for me it’s right now only to be prepared for problem diagnosis and not for performance measurement.
I suppose that the Custom UI path is used by others as well and so I’m wondering that these kind of questions are not asked so far.
So my last 2 questions are still open for me.