Finding the source of an object creation in Codeless

Server Code Codeless
1

Hi there,
I am getting some double entries in one of my tables, but as I now have numerous methods and timers that are affecting each other, I am having trouble getting to the source of the duplication.

The duplication is not coming from the UI but from an internal update.

Is there a best practice using loggers or some other method do look at the objectId of the duplicate entry and understand the path or sequence of steps that occurred? I don’t know if adding a logger to each method will allow me to track specifically how a certain object was created.

Thanks.

2

Hello @Andreas_Marinopoulos

Unfortunately we have no other way of debugging except to log everything.

Regard, Viktor

3

Hi Andreas,

If you have any ideas for how debugging codeless logic might be implemented, please let us know. This is one of the areas we’d like to improve.

Regards,
Mark

4

Sure @mark-piller ,

I really think a UI like Zapier would be useful

image
image2297×1095 221 KB

image
image2414×614 70 KB

If you can show where the error is occurring at the block level with the associated information, it is much easier to debug.

image
image1374×1374 164 KB

Right now the process I have ended up with is

  1. Disabling all blocks in a method, adding print blocks everywhere.
  2. Enabling 1 set of blocks, deploying, invoking, looking at the log.
  3. Enabling a second set of blocks, deploying, invoking, looking at the log.

I understand what would be challenging is that Zapier has very simple linear code whereas Codeless is much more powerful with lots of transformations and conditionals.

But you could possibly find a way to create fictional steps or containers of code, based on whichever blocks are touching the left side of the canvas. Or could could add a type of debug block that “separates” the code into containers that would then appear in the Zapier-like steps above.

Just my two cents…

5

Thank you for sharing your thoughts. This is not trivial at all as a block that causes an error may be deeply nested inside of logic, yet the error it produces would bubble up to the top and may not be handled at all. Every block results in some code, whether it is an assignment, conditional, API call, arithmetic, etc. Being able to track at a block-level would mean that for every single element of code generated from block there would need to be a monitor that tracks the execution of that code. In some cases, it may be simple (such as API calls), while for most, it is not or not possible at all.