I appreciate the debugger as well as the ability to view server logs. Yet, both are quite limited in their own way. The first interfering with the GUI (and nearly impossible to use when using an “every N seconds” trigger. The second is visually confusing and information is difficult to understand and logs cannot always be retrieved.
Currently, as a workaround, I create logs as actions meaning I’m inserting actions in my workflows and log a text as a database under data type “logs”. That’s actually a lot more efficient than using the other logs, especially when I have recursive workflows that need to create multiple things.
Even better though, would be the ability to have these logs with/on actions, i.e. to be able to edit a text, with the usual dynamic input available, which would create a log item in the database. This would allow to create a precise “console” output for each action. There should also be variable in there to refer to the Workflow and Action, should it be required, as well as a Timestamp.
3 Likes
The debugger is limited in many ways (it’s biggest is it does not reveal the true asynchronous manner in which Bubble executes larger workflows). It’s biggest use is to uncover the conditional resolutions along the execution path of a workflow to uncover a logic breakdown. Although, be advised such conditionals are evaluated in POST-EXECUTION, hence any DB updates actually perform prior to the debugger walk-through.
You’re already on to your own finding for the logs: you need to construct your own logs table to allow for more precise control of what you need, as well as query-ability and filtration for Ops control. Thousands of users on an app simultaneously leaves the native logs in the dust for usability. In-house logs that are written to for the important events, that you can then build admin consoles to query against are the best long term solution.
1 Like
Thanks. Do you think the idea suggested above: i.e. logs in-action rather than in-between actions in a workflow, would make a difference?
Not really. Reason is Bubble tends to “batch” your DB creation statements if it determines it can. Personally, I leave my log-entry-creation actions separate as their own actions within a workflow. This is simpler, and performance hit is negligible.
Edit: To get around the batching and enforce Bubble ONLY creates a log entry if the prior DB step occurred (helpful for precision scaffolding and triaging), is to reference some value from that preceding DB step, within the log entry creation. Such as “some_field = Result of Step X’s any_field_you_want’s value”. within the log row creation step. This works for all DB manipulations EXCEPT for actions that are deletes. For deletes, Bubble doesn’t return anything hence you can’t reference it in a successive log-entry step. (Which I think should be an enhancement request now that I think about it, returning rows-deleted is a standard DB action that is usable in many cases).
1 Like
