FP-2988: Can't create Callback from node subscriber port "+" button

[quirinpa]

• FP-2988: Can't create Callback from node subscriber port "+" button

[manuelnogueiramov]

I think the solution is quite like what you've done, but I'm afraid this way it might cause a racing condition. Having 2 promises running side by side and the last one is dependent on the first. I would suggest using async await here, this way we know that the promises are called when they are supposed.

[quirinpa]

I would agree with that, Manuel.

Are we ensuring that the promise only resolves if the action is completed?

[manuelnogueiramov]

I would agree with that, Manuel.

Are we ensuring that the promise only resolves if the action is completed?

Didn't understand what you meant here.

[quirinpa]

I meant if it was an asynchronous action, I was asking if we were ensuring that it'd only resolve on completion.

But I looked into it and saw that it wasn't an asynchronous call. So I think your comment does not apply.

[manuelnogueiramov]

I meant if it was an asynchronous action, I was asking if we were ensuring that it'd only resolve on completion.

But I looked into it and saw that it wasn't an asynchronous call. So I think your comment does not apply.

call returns a promise. So, yes it's an asynchronous call. Which means that in some weird case CREATE can finish after the SAVE, which will cause errors. This can be simply fixed by adding async await here

      const handleNewCallback = useCallback( async (defaultMsg, ioConfigName, portName) => {
      const scope = CallbackModel.SCOPE;
      const tempName = "new_callback";
      await call(PLUGINS.DOC_MANAGER.NAME, PLUGINS.DOC_MANAGER.CALL.CREATE, {
        scope,
        name: tempName,
      });
      await call(

[quirinpa]

Even though call returns a promise (in some instances, at least), which it has to to ensure that remix plugin method calling mechanism supports async methods and promises, it doesn't necessarily mean that we have to use an await there.

The code of the function is synchronous. The call implementation most probably calls the function synchronously and returns its result, which might be a promise, or not.

Not having await there doesn't break anything. And adding it might. I don't have indefinite time for tasks, so please, consider spending less time holding my tasks. I don't pay you with the same coin and would appreciate that you stopped doing that.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[diasnad]

Did you test both options to see if any would bring regressions?

[manuelnogueiramov]

What issues could adding an await there, that would in fact make sure that we only run the next code after we get the promise, can happen? What am I overlooking?