Various Console Issues or Enhancement Suggestions

Describe the bug All execution lines in the console get the same timestamp, which is updated in real-time during execution to "current-time", rather than being a ~ 'new Date()' for each execution line sent to the Console.

Also, for the minutes part of the timestamp, when under '10' (e.g. 1, 2, 3, ..., 9), it is badly formatted: missing the "0" in front (see screenshot, will be easier to see in action).

To Reproduce Steps to reproduce the behavior:

Create a new request with some pre-script
Include some console logging into your pre-script, like "kr.console.log(*** EXEC START TIME: ${startDateTime});"
See the 2 reported errors above

Expected behavior Each execution line in the console should have its own execution time.

Screenshots Screenshot 2024-10-15 at 6 01 18 PM

Desktop (please complete the following information):

OS: macos
Version: 1.0.67

1- Also, as I kept playing with my pre-script and watching its execution in action with the Keyrunner Console, I just realized that I always need to keep scrolling manually down "during" the pre-script execution to see the latest info being logged to the console.

So, it would be really nice if we could have the Console to automatically scroll down (like unix/linux "tail -f" command) for you, during the request's pre or post script execution.

2- Also, I think that it would be nice to add the name (key) of the env variable being updated/saved to the console log entry, or else it just seems to me as trace/noise/~spam information that doesn't provide much value as it is right now..

Screenshot 2024-10-16 at 2 16 47 PM

perhaps add some filtering capabilities to the Console, so that we can actually filter out all those "Successfully updated environment variable" tracing-level logs?
perhaps combining the 2 log lines "Sending POST request to http://...." AND "Sending Request Data: {...}" together in one single console log line would also be really nice in the goal of simplifying current Console logs, hence improving its usability/clarity/UX ?

It would be nice to have the Console to be showing ONLY 1 log line per REQUEST (expendable to see all its details, e.g. request {headers + body} and response {headers + body}), plus custom user defined logging (if any), but without any additional keyrunner app logging such as all those "Successfully updated environment variable" logs, so that we obtain in the end something really tight and clean and easy to see what's going on, all the requests that have been executed from a given collection, similar to what Postman is doing with their separate Console view, and eventually even make it searchable: Screenshot 2024-10-16 at 3 05 57 PM

Screenshot 2024-10-16 at 3 21 28 PM (+ add some different colours for json keys and values, like the postman screen above ☝️, to make the console json content easier to read to the eyes ?)

Here's an equivalent view of the Console as of today (1.0.67) in Keyrunner: Screenshot 2024-10-16 at 3 37 31 PM

And some more versions of it, with annotated comments: Screenshot 2024-10-16 at 3 42 23 PM

Screenshot 2024-10-16 at 3 43 07 PM

Screenshot 2024-10-16 at 3 38 25 PM

thanks

Some more feedback, while we're at it through current ticket.. (obviously, let me know if I should instead be opening various different issues +- for each screenshot containing some Console feedback)

see screenshot annotated comments:
make the whole Console panel "expendable/draggable" (similar to how the Response panel behaves..), so that it is possible to increase its height / size, and allow to see more log entries; this becomes especially useful when, for instance, you expend some post queries (by clicking on those ">" characters/links) and looking at those requests' details, they'll obviously take more space when expended and we have to start scrolling up and down to navigate the details etc, and considering that we may see one day an enhancement - as already listed in some previous comment up there - that would enhance the post "data" (currently displayed as a json-non-formatted-one-liner-string) to be displayed just like how it is done in Postman (see one of the postman screenshot above re one of the expended post request node..), e.g. displayed as a true formatted json structure using multiple lines (...as many lines as the size of the json request body payload, which could take up to an hundred of lines for super large payload - postman is even treating those larger payload that are larger than X lines and provides a link to view the whole payload in another separate scrollable full-screen panel to make it even easier, but under that X value, they display the full request body json payload directly in the console, and most importantly, all json-formatted for a great user experience..), so it would definitely justify the need for allowing to augment the height/size of the Console panel, rather than having its height fixed/hardcoded as it is the case currently in 1.0.67 (it would also be nice to allow to do the other way around too, and have the ability to 'reduce' its size almost to zero through a mouse-drag down, e.g. just enough to still see the top blue bar of the console panel and that's it, when you want to quickly hide it and focus on the rest of the application panels like when editing a large multi-lines json request body or analyzing a large response json payload, but still, you don't want to have to 'close' the console panel and have to re-open it afterwards, since you still want to play with it soon enough so you want to keep it opened and ready to be expended again through a mouse-drag up!):

@frank-duq We will handle all console tab changes as a single issue . Our plan is to keep delivering 2-3 features at a time and keep this thread open for any feedback or suggestions.

Thanks again for providing such a detailed explanation of the requirements!

Sounds like a plan 👍, thanks!

@frank-duq we have incorporated a couple of above mentioned changes in V#1.0.69 .Let us know your thoughts and if any further improvements are needed

Very nice work @launchiamenterprise, this definitely feels like Keyrunner 'Console' 2.0, much better looking and overall experience playing with it!

Now, if you allow me to continue adding more feedback into it, I can definitely share a few more bits about it:)

Separate the most important console logs from the least ones, by splitting them into different log levels/categories, and allow more fine-grain filtering of the console logs (but hey, nice work already, it's definitely going in a great direction with the recent filtering updates!):
Coming back to this feedback mentioned previously, you can definitely ignore obviously if you don't agree or too much complex to implement whatever, but I still think that it would be a great to have / great UX enhancement - just like postman is doing with their console - if we could only include the "expend" icon next to log messages that actually contain more info, so that user doesn't loose time expending them all to find if there's additional information available, or not! Over time, this becomes a little bit annoying, UX-wise.. (basically, suggestion is either to 'remove' the expend icon when there's nothing to expend, OR put a different non-clickable icon like a "-" or equivalent, that tells the user there's nothing more available than the log message already displayed..).
Format the json "data" node of the request being sent (same applies to json response data actually):
Console Performance No screenshot for this, I could record a short video if needed, but there's definitely an odd delay after running a request, and receiving the response, before the Console starts to display the request/response execution logs, which feels weird. Ideally, the Console would display in real-time line by line, as they are being executed, e.g. if my pre-script executes and logs something to the console, I should see that log in the console 'before' the request is actually submitted by keyrunner to the remote server, and then, the request gets logged to the console when it's being sent, followed by the response, when it's received, etc etc...
Reduce overall padding/spacing for each record The new Console redesign looks much much better than before, big kudos, looks more professional now, and is actually more usable also. One suggestion though, is that it feels to me like if we could reduce the padding inside each record, so that we can actually see more info / log records. Generally speaking, I like when UI can breathe, and adding extra spacing / padding a little bit every where is definitely the way to go imo. However, for presenting several records in a table, such as a Console presenting log records, there's a tradeoff/cost at allowing more spacing/padding, and it is usually acceptable imo to have a more compact design to present the rows, for the benefit to see more records for any given table/panel height. Ultimately, to make everyone happy, there can always be a new configuration option/setting added to some Console top-right menu, that could allow a user to select between a more compact or stretch/comfortable 'density' layout, similar to what Gmail offers in its main setting cog icon menu, but that's definitely not a must have imo, just having a slightly more compact design/layout for the log records of the new console design would be more than enough, but again, this is just my humble opinion, cheers.
Include env var's value in the [ Successfully updated environment variable "env-var-name"... ] debug/trace log message I should have suggested to include not only the env var name (thanks for that, really cool) in that system debug/trace log msg, but also the value, while we're there, e.g.:

[ Successfully updated environment variable "env-var-name" to "env-var-value"... ]
For this one, I know the impact with current implementation/design might be bigger, and you may just not be interested in doing such regrouping, since I can see some minor advantages for keeping them separate, but it comes with the drawback that the console becomes much more verbose overall, when executing multiple requests, it means 2X / twice as many records overall... (postman went in the direction to regroup them into 1 log record only for each request/response roundtrip, but it's really up for debate, I don't have extremely hard feelings on this one, I can see pros and cons on both approaches, but I have the feeling that merging might offer a slightly better overall experience, by keeping the Console leaner / less verbose.....so it's definitely worth considering imo. And if YES, I would suggest that the Request log record appears as soon as it is being sent to the server, to reflect reality in real-time (let's not wait for the entire roundtrip to be over before displaying the sent request to the Console, since some network roundtrip and/or server processing may take longer, but we do want to see in the Console in the meantime that the request has been 1- generated and 2- sent, meanwhile we wait for the response..), and that such request/response roundtrip log record gets updated with the response results/information once the response comes back.

@frank-duq Thank you for your feedback and inputs! We will actively work on addressing these changes and incorporate them in upcoming releases. Here is the break down of tasks , let us know if we are missing anything . We will keep this issue open and strike off the tasks as they are implemented.

[ ] Split Console Logs by Levels/Categories
[ ] Optimize Expand Icon for Log Messages
[ ] Format JSON Data Node
[ ] Improve Console Performance
[ ] Reduce Padding/Spacing for Records
[ ] Include Environment Variable Value in Logs
[ ] Merge Request/Response Logs

Wonderful news, and yes that's exactly it!

The only little thing I would add to the suggestion I made re Include Environment Variable Value in Logs, is whether or not that could become an issue to log sensitive env var's value (security wise), and wondering if perhaps this should be controllable perhaps through some new Console setting, to allow configuring whether or not user wants to see the env var's value in the logs or not, and for security concerns, it should be disabled by default. Since this is making this suggestion/feature request larger now with such security concern in mind, perhaps it makes it not as important as the other ones, e.g. a nice-to-have..

thanks!

launchiamenterprise / keyrunner

Various Console Issues or Enhancement Suggestions #74