Scheduled actions status icons

[Apple]

The proposed feature request adds green and red circles near the scheduled action names, such as:

These icons would represent the status of the last execution.

Behind the hood, NodeJS would keep in an array the status of the last execution of such schedule. The UI would call the NodeJS app to inquire about this array/status.

A green circle is an execution that succeeded without errors. A red circle is an execution that threw an uncatched error/exception.

It would be great to see the error of failure, so this array could hold the output of the execution. Perhaps it would be best to keep the last 10 executions for each scheduled action.

[sid]

This is local system you are talking about.
There is no way for Wappler to know about the statuses when an app is actually deployed.

What you need is a try-catch mechanism and a log in DB to capture failed attempts.

[Apple]

@sid

This is local system you are talking about.
There is no way for Wappler to know about the statuses when an app is actually deployed.

Actually, the app could store the array in Redis and Wappler UI could communicate with the app through the secret route it uses for the database manager I think. I'm not at the computer right now, but in the NodeJS source I found there's a secret route (authentication protected) for executing DB queries I think - unless I'm missing something and this only works in local

And i just came to realise if multiple instances of the app are running, the scheduled tasks might run in parallel as well, so it's missing a locking system that uses Redis

[George]

I think we should do some logging of the action execution status first @patrick and then we can do nice things with it.

[sid]

@Apple

the app could store the array in Redis

I don't use Redis. Like many other users here. So if its a very specific solution for a very specific use case, I don't think this makes much sense.

@Apple

in the NodeJS source I found there’s a secret route (authentication protected) for executing DB queries

I have no idea about that. But from what I know, it just uses the credentials provided by the dev to connect to the DB.

[Apple]

@sid

I don’t use Redis. Like many other users here. So if its a very specific solution for a very specific use case, I don’t think this makes much sense.

When I say "could store the array in Redis", it would also work for those not using Redis, just like sessions. I'm just making proposals based on what already exists: If the user is using Redis then store in Redis, otherwise store in-memory NodeJS array as initially intended

@George

I think we should do some logging of the action execution status first @patrick and then we can do nice things with it.

Sounds good

[sid]

@Apple

If the user is using Redis then store in Redis, otherwise store in-memory NodeJS array as initially intended

This now going over my head
Lets see what the team can come up with for this.