Debug plugin server side action?

Plugin builders
1

Hi Bubblers,

I am trying to link to my thermal receipt printer. What i’ve observed is if I use an outside API to print, it prints instantly. If i put the print code in my plugin and use the plugin to print, I have to click 3 times on print before the first item gets printed out. This means that effectively, the first 2 items are placed in a ‘hold’/‘queue’ somewhere and are only pushed out when the 3rd item comes in. I have verified that it is stuck in Bubble’s server because when these 2 items are in queue, i can still test print from my outside API.

Is there any way to debug the plugin server side action? Because we need to use the node modules, is there a way for us to debug it.

2

Something useful that I do is to run it locally, in my pc’s Node.js environment.
I usually have a standalone version of the server side action that runs on my node and a plugin action version (with all the properties.something and context.something required).

Also, do you get any error message?

3

Yes, we did that already, running it locally generates no error.

There is no error for Bubble as well. The print order is still there, just that it is stuck in a queue somewhere in bubble’s server, and will only output the first print after the third print order comes in.

4

That’s really weird.

Isn’t it something about when the workflow itself is running? Instead of looking inside the action, maybe there’s some clue on the train that carries the action. Maybe the workflow gets stuck or is delayed somehow.

Can you try to track when it runs? Maybe creating a thing on the database (like a custom log) and seeing the time the wf fires by looking into the creation date (look at the minute and seconds there). Maybe a create thing action before the plugin action and another one after, and each workflow will create different log things so you know which thing belong to whick workflow (first, second or third workflow).

Or looking at the app’s log provided by Bubble, maybe there will be something useful there regarding the workflow that fires the plugin server side action.

5

I was using this code in my plugin. I looked at the log. Basically, the first 2 times i click print, the print data gets stored on bubble but the print order does not successfully send out. but when i click print the third time, somehow the print order sends out and the first data value gets printed.

The funny thing is, if i run the exact code below in node.js, it works perfectly. So it is definitely a Bubble issue. Any ideas?

var http = require(‘http’);
var qs = require(‘querystring’);
var crypto = require(‘crypto’);
var USER = “loh.cher.e@gmail.com”;
var UKEY = “tgQB6c9zsvenhKhB”;

var HOST = “api.feieyun.cn”;
var PORT = “80”;
var PATH = “/Api/Open/”;

var sn = “918800335”

var orderInfo = “test”;

var STIME = Math.floor(new Date().getTime() / 1000);

var post_data = {
user:USER,
stime:STIME,
sig:crypto.createHash(‘sha1’).update(USER+UKEY+STIME).digest(‘hex’),
apiname:“Open_printMsg”,
sn:sn,
content:orderInfo,
times:“1”
};
var content = qs.stringify(post_data);
var options = {
hostname:HOST,
path: PATH,
method: ‘POST’,
headers: {
‘Content-Type’: ‘application/x-www-form-urlencoded; charset=UTF-8’
}
};
var req = http.request(options, function (res) {
res.setEncoding(‘utf-8’);
res.on(‘data’, function (response){
console.log(response);
});
});
req.on(‘error’, function (e) {
console.log(“error!”);
});
req.write(content);
req.end();

7

Anyone with javascript experience and who knows how to debug a plugin? Willing to pay for someone to look through my plugin.

8

Ah, possibly not the issue, but definitely something worth looking into: calling asynchronous stuff on server side actions must be done through Bubble provided functions context.async and the context.request.

Not using the proper async functions may lead to that kind of error you’re experiencing.

I see that your code isn’t using the context.request, that’s how you use it:

const options = {
    uri: "https://whatever.com",
    method: "POST",
    body:   {
    }
  } ;

 let response = context.request(options);

Don’t focus on the options object, it’s the same as within a normal node environment.
Just the way you can call the request is a bit different

Regarding other async functions you may be using, you have to convert them to fit the context.async function like I share in this post.

Try running your action after fitting all the async calls.

5 Likes
9

Along the line of your last comment, I’m writing a plugin that does an API fetch and needs to API call result code (200, 401, etc) which the Bubble API connector doesn’t provide.

For that reason, I’m writing a plugin that mimics the bubble API Connector, AND includes the API call returned status in the returned object.

I have found your insights on context.async to be very useful, but I really need to see the output of my console.log messages to debug the logic.

Right now, my plugin returns an empty object, which in and of itself is progress as it shows I have the context.async syntax right.

I too “mock up” my Plugin Action code in NodeJS before I refactor it into Plugin Action code.

However (and here comes the question):

How do I create NodeJS code that mimics the context.async syntax?

If I could figure that out, I could debut the logic issue in NodeJS, then simply port the code into the proper Plugin Action code.

Alternatively, if there any way I can see the console.log messages within Bubble, that would also suffice.

Any ideas?

10

There isn’t, and likely won’t be for a long time, so let’s not hold our breath waiting for this here…
A good question you made, indeed, as I think that it’s likely that you can mimic the context async by creating an anonymous async function in Node, try these two readings about this here:

and

Let me know how it goes and happy bubbling (:

11

How are you running a plugin locally? Just running the script and then passing in mock “properties” and “context” values?

12

In node, locally installed in my computer.
I create two versions of the code, so two files, one that I run locally with static values and once that first one works fine, another one “bubble-fied” where I swap things for “properties. context.” etc that I paste in the plugin editor.

13

Mind pointing me to an example?

My plugin makes use of functions such as ‘listProperties’ and ‘get’, which would mean I have to mock them just by looking at the response types which I don’t really have access to given its a server action…

14

Instead of using “listProperties” use [“one”, “two”, “sample”] :blush: