You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the job logger - the thing that logs user's console.log statements - I could (probably) detect an undefined value and pass an 'undefined' string instead. Now Lightning will receive message: ['undefined']. I don't know if that will confuse anything. I suppose I could also do message: [undefined] if an argument was passed, which is probably more useful
The logger has console.break() function, which I think is mostly what the CLI uses for this. I could have a rule like: when logging json output, ignore any console.break statements - because we assume that the JSON will be consumed by something richer that a terminal downstream.
The worker could refuse to send any logs with message: [] on the assumption that it's a waste of everyone's time
If I do that, then I think I can promise:
message: [undefined] is useful and even important to log
*You will not be sent meaningless empty lines which are just stdout padding
The text was updated successfully, but these errors were encountered:
Don't send empty log lines to Lightning. Do send
console.log(undefined)
, especially in job code, because it might be important.From discussion at: OpenFn/lightning#2959
In the job logger - the thing that logs user's console.log statements - I could (probably) detect an undefined value and pass an 'undefined' string instead. Now Lightning will receive message: ['undefined']. I don't know if that will confuse anything. I suppose I could also do message: [undefined] if an argument was passed, which is probably more useful
The logger has console.break() function, which I think is mostly what the CLI uses for this. I could have a rule like: when logging json output, ignore any console.break statements - because we assume that the JSON will be consumed by something richer that a terminal downstream.
The worker could refuse to send any logs with message: [] on the assumption that it's a waste of everyone's time
If I do that, then I think I can promise:
message: [undefined] is useful and even important to log
*You will not be sent meaningless empty lines which are just stdout padding
The text was updated successfully, but these errors were encountered: