So, what would happen if I used the

record.create.promise

in a restlet? Meaning .. I want to capture the incoming payload in a custom record, but also want to return a 200 as a response as quickly as possible (since the status of the operation isn't needed in the response)

I haven't tried it but I think restlets are synchronous - give it a try and report back?

meaning that you want a response written but continue to process? You can definitely do this. Promises or not. You won’t be able to respond again and update your response ( w/o some other magic not shown here)

Agreed.

If it doesn't matter could you do the reverse and have NetSuite just poll for whatever it needs?

One way @creece

If you're just creating a custom record and returning I can't imagine thats slow enough to create something that'll be quicker

all true statements @creece... just pushing envelopes I guess

actually, the important this is whether your promise code did complete even though the response was returned?

And further .... https://tstdrv2228040.app.netsuite.com/app/help/helpcenter.nl?fid=section_4387812940.html

don't be sad! The most common workaround I see here is folks doing a rudimentary queue mechanism where the restlet only saves the input to a custom record, then immediately returns. A scheduled script or similar comes along later to process the data async

What's interesting though is I was able write the

promise

and not only did it run, but ran successfully.

I thought you confirmed the promise did not work as expected? Simply creating a promise is rather useless compared to doing something when the promise resolves

I'm still experimenting

it’s not that you can’t run promises at all… it’s that there is no benefit to doing so for

N/record

and no api…..YET. Behind the scenes (outside the JS REPL) an operation like reading a record from the database might benefit from offloading that via threading but it has to be implemented that way. NetSuite doesn’t tell us where these optimizations have been made but there are clues such as promises being available in the api. So it seems to have been done for search and query and web requests. If you really wanted it to be a promise /async structure you could wrap it in a promise. c.p. there’s no performance benefit to it on the server-side. let’s say they were planning on having internal optimization for N/record. Then making a promise method available would make sense. You could write code today that does not perform better but logically expects it to be asynchronous. When it becomes asynchronous then you get the benefit automatically without a re-write. in short, Today you could stick

record.create

into a promise simply with

Promise.resolve(record.create({options}))

hypothetically if record.create.promise becomes available on the server side you can rewrite that one line to take advantage and logically everything would still flow. if you’re feeling optimistic or have some insider knowledge, you could have your stub or proxy for it. Logically equivalent to this ugliness:

Promise.resolve((create=>create({options}))(record.create.promise || record.create)).then(/*etc*/)

i’m not suggesting you should do this — simply trying to keep the neurons firing.

I definitely wouldn't do any of the above.