Support for node status list and duration

Core Development Feature Requests
42

Honestly I don't know if the error status should trigger the status node.
It's also the role of catch node (because node.error is called).

43

You already said that you thought ephemeral statuses should not trigger the status node and I think that is correct. In any case, an error should trigger an error, you should not rely on status for that I don't think.

1 Like
44

I understood it now. I can see ephemeral and duration as independent variables.

  • ephemeral when true it does not trigger status nodes/effects and and it also does not change node._previousStatus, which is managed by the core.
  • duration when set the node goes back to its previous status using node._previousStatus when the configured time has elapsed

For your query example, I agree ephemeral makes sense because you just want a visual status change, but I don't see how the runtime would change the status back to node._previousStatus once the query promise is done. @GogoVega Could you explain in details how you plan to do it? I donā€™t think duration would work because the status must go back to the previous static status only after the promise is resolved. obs: try/catch and other node code details were ommited

async onInput(){
     // suppose the db connection is already opened and status = Connected (static status)
    
    await this.query();

    ....
}


async query(){
      this.status({ text: "querying...", ephemeral: true }) // change status visually only

      await this.db.model.fetchMany(...)

      // how would the runtime change the status back to node._previousStatus only when the above promise is completed????
   
}
45

My side:

async query(){
      this.status({ text: "querying...", ephemeral: true }) // let's say the default duration is 5s - the process took <1s

      await this.db.model.fetchMany(...)

      this.status({ text: "query done", ephemeral: true, duration: 200 })
}

The idea behind the runtime is to use the current variable retained which only keeps static statuses. When it is an ephemeral status, we add the static status into the ephemeral status and it is the editor which will visually handle the transition. Same principle with static status and duration except that retained will not change - so it can be restored.

46

[removed initial interpretation to avoid emotional damage due to impulsiveness]
Sorry. I interpreted it wrongly. I understood it now.

It will be

  1. Connected
  2. querying...
  3. query done
  4. Connected

Because it took <1s for the process to finish.

Now lets suppose the process takes >5s and there is a default duration of 5s when using ephemeral without setting duration. Then

  1. Connected
  2. querying...
  3. Connected
  4. query done
  5. Connected

And this would be wrong. That is why I think ephemeral shouldnt have a default duration. Unless you have a plan to fix this possible issue

47

Yes and no, as I said in my scenario, the process should take < 1s, so "querying..." (which normally takes 5s) will be replaced by "query done":

  1. Connected
  2. querying...
  3. query done
  4. Connected

No worries :wink:

1 Like
48

I added the right interpretation i was thinking. How would this be avoided?

49

Yep, a possibility is a null value.

The subtlety is that this status is infinite but only in the editor that received it; an editor refresh makes this status disappear :zany_face:

50

So can we agree that there is no default duration when ephemeral = true?

51

Both possibilities are good. It's up to our gurus to decide :slightly_smiling_face:

It will depend on the use that is most likely to be used.

53

That is fine. I support both attributes, as long as they are independent. Good idea. :+1:

54

This is understandable for a query that always takes a long time. Eg AI :slight_smile: but most situations they are much quicker and can handle multiple queries per second if not hundreds. You donā€™t really want to send something to status for every passing message unless you want to kill the editor performance.