How to set the message of the banner (red/green/blue) returned to the UI on action completion

Hey there!

I am having a small issue understanding how I can properly set the text which is returned to the UI (inside the red/green/blue banner that appears on the bottom right).

Also, I would like to know if I can set the color of the banner (I have green on 200, red on 500). Can I use blue like smart action or any other color?

Expected behavior

With this piece of code, I expected the text within the banner to be set:

response.status(200).send({success: "You made it!"}); // working
response.status(401).send({error: "Oups... It seems you can't do that."}); // not working

Actual behavior

I have texts corresponding to errors/crash (which seems kinda random based on the situation) but I am not able to set the inner text.

Context

{
  "name": "my-project",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "node ./dist/server.js",
    "build": "rm -rf ./dist && npm run compile",
    "dev": "tsc-watch --onSuccess \"node ./dist/server.js\"",
    "compile": "tsc",
    "lint": "eslint . -c .eslintrc.json --ext .ts"
  },
  "dependencies": {
    "@google-cloud/pubsub": "^2.17.0",
    "@types/express": "^4.17.13",
    "@types/mongoose": "^5.11.97",
    "@types/node": "^16.3.3",
    "abort-controller": "^3.0.0",
    "body-parser": "^1.19.0",
    "chalk": "~1.1.3",
    "cookie-parser": "1.4.4",
    "cors": "2.8.5",
    "debug": "~4.0.1",
    "dotenv": "~6.1.0",
    "express": "~4.17.1",
    "express-jwt": "6.0.0",
    "forest-express-mongoose": "^8.3.0",
    "mongoose": "~5.8.2",
    "morgan": "1.9.1",
    "node-fetch": "^2.6.2",
    "nodemon": "^2.0.12",
    "require-all": "^3.0.0",
    "ts-node": "^10.1.0",
    "tsc-watch": "^4.4.0",
    "typescript": "^4.3.5"
  }
}

Hey @Emixam23 ,

For the color of the toaster you can’t choose it. It’s green for success and red for error.

About the error one, did you try with the status 400 instead ?

Hey :slight_smile:

It doesn’t change anything :confused:

Thanks!

Max

Hi @Emixam23 :wave:

When you talk about action completion, you mean in a smart action context or in a route override (POST/GET/…) ?

In a smart action context, and according to the documentation, { error: 'This should be displayed' } should work. I’ll give it a shot just to be safe.

Let me know

Hello @jeffladiray

Alright so, first, I think I do have to apologize as I am always use to post detailled issue. This time I feel like you’re missing information, so I am really sorry about it :confused:

Actual Behavior

So, if we take forest admin routes responses, based on request(s), we (from my pov) have 4 different basic situation:

- Action: success (200?)
- Action: error (500?)
- SmartAction: success (200?)
- SmartAction: error (500?)

Even if there can be different relative codes, such as:

  • 401 Unauthorized
  • 201 Created
    Let’s focus on 200 & 500 for now.

If we have only two scenarios possible, success or error, then here you can find the behavior for each scenarios:

  • Success message within body (200) on Action
    1
// Create a Product
router.post('/products', permissionMiddlewareCreator.create(), (request, response, next) => {
    // Learn what this route does here: https://docs.forestadmin.com/documentation/v/v6/reference-guide/routes/default-routes#create-a-record
    let message = "hey";
    console.log(message);
    response.status(200).send({success: message});
    return
});
  • Success message (200) on Action
    2
// Create a Product
router.post('/products', permissionMiddlewareCreator.create(), (request, response, next) => {
    // Learn what this route does here: https://docs.forestadmin.com/documentation/v/v6/reference-guide/routes/default-routes#create-a-record
    let message = "hey";
    console.log(message);
    response.status(200).send(message);
    return
});
  • Success message within body (200) on Smart Action
    sm-1
// Release to prod
router.post('/actions/products/release-to-prod', permissionMiddlewareCreator.smartAction(), (request, response) => {
    let message = "hey";
    console.log(message);
    response.status(200).send({success: message});
    return
});
  • Success message (200) on Smart Action
    sm-2
// Release to prod
router.post('/actions/products/release-to-prod', permissionMiddlewareCreator.smartAction(), (request, response) => {
    let message = "hey";
    console.log(message);
    response.status(200).send(message);
    return
});

So as of now, we can see that the message seems unmutable within action. However, for smart action, sending a message within the body works (using success field).

  • Error message within body (500) on Action
    1
// Create a Product
router.post('/products', permissionMiddlewareCreator.create(), (request, response, next) => {
    // Learn what this route does here: https://docs.forestadmin.com/documentation/v/v6/reference-guide/routes/default-routes#create-a-record
    let message = "hey";
    console.log(message);
    response.status(500).send({error: message});
    return
});
  • Error message (500) on Action
    2
// Create a Product
router.post('/products', permissionMiddlewareCreator.create(), (request, response, next) => {
    // Learn what this route does here: https://docs.forestadmin.com/documentation/v/v6/reference-guide/routes/default-routes#create-a-record
    let message = "hey";
    console.log(message);
    response.status(500).send(message);
    return
});
  • Error message within body (500) on Smart Action
    sm-1
// Release to prod
router.post('/actions/products/release-to-prod', permissionMiddlewareCreator.smartAction(), (request, response) => {
    let message = "hey";
    console.log(message);
    response.status(500).send({error: message});
    return
});
  • Error message (500) on Smart Actionsm-1
// Release to prod
router.post('/actions/products/release-to-prod', permissionMiddlewareCreator.smartAction(), (request, response) => {
    let message = "hey";
    console.log(message);
    response.status(500).send(message);
    return
});

We can note from these error that if you send a clear string message on action error, it works but you get an extras Products creation failed: in front of your message. On smart action it’s totally KO :confused:

We these 8 examples, we can see that the behavior isn’t the same all time between success & errors, but also between action & smart actions…

Expected Behavior

It doesn’t matter if I specify a body or just a string, based on the code type (2xx, 4xx, 5xx), the result/behavior should be the same between action & smart action.

Bonus

It could be amazing to choose he toaster color ! :slight_smile:

Thank you so much for your time, I hope it helps :slight_smile:

Best,

Max

1 Like

@Emixam23,

Thanks you for this deep analysis of the issue. This is way more detailed than I was expecting :smiley:

Indeed, you are right, and I was able to reproduce the issue. Toastr for actions and smart actions are handled differently on our end, most likely due to the fact that smart action have a few specific keyword to achieve different goal than classic action (refresh, webhook, etc…). These keywords are not especially useful in an Action context, so that might explain why the behavior is different.

Let me sum this up:

For 200 status code:

  • Success message within body (200) on Action → This is not supposed to be handled for now, so I’ll push this as a product board suggestion. However, you are theoretically supposed to send back the created resource instead of a message.
  • Success message (200) on Action → The unexpected error looks weird indeed. However, this is an incorrect usage of the API. It does not look that weird to me, however a log message/a clear reason for the unexpected error would make this better I think
  • Success message within body (200) on Smart Action → This one looks good to me :+1:
  • Success message (200) on Smart Action → Same as before, this looks like a mis-usage of the API we provide, but I’m actually surprised that the behavior is not the same as before.

For 500 status code:

  • All of theses does not look natural to me. I’ll sync with the team to check, but for example Error message within body (500) on Smart Action looks more like a bug to me, according to the documentation

Anyway, thanks for pointing theses inconsistencies. This is a very valuable feedback :pray:
I’ll sync up with the team to check if I’m not missing something :slight_smile:

1 Like

Hi!

Thanks, I appreciate it helps :slight_smile: I was kind of tired when i posted so I haven’t put much details… sorry again!

Well yes I think it would be better to have a comon system to print message back to the UI. Also, toast color could be a great add to your system.

So ok… you sync up with your team meaning… what? Like you will suggest some changes or are these scenario “bugs” that you might fix soon? I am asking because I don’t know what to do right now… We use forestadmin but on error, we must check Heroku log to understand what’s happening… it’s kind of boring ^^’

Thanks tho :slight_smile: We appreciate the help!

Max

According to me, a few cases you mentioned in your detailed response are indeed bugs - Especially the one on smart action, but I might be wrong. I prefer to check with the team in charge of the topic the expected behavior and if there are any reasons that forces use to have this behavior. (Like 500 on smart action within body)

A few cases you mentionned also looks like feature request, since I’m pretty sure some toastr was design to not be as flexible as smart action one (Like 200 on Action within body).

Once I can sync up with the team, I’ll make you a detailed feedback of what is considered as bug, and what’s not, so you can act accordingly on your end.

Thanks for your patience :pray:

I’ve just discussed with the team in charge of the topic, and here are my conclusion:

Smart actions
Smart action response are not consistent accross documentation, http status code & format. This is indeed a bug, so I created a ticket on our end in order to have a correct behavior. Be sure you’ll be pinged once fixed (As usual, not ETA available)

The bug report for smart action contains a link to this thread, directly to your deep analysis of the toastr system. It is focused on smart action so I can’t assure that the fix will include classic action response as well

Classic actions
After a deep discussion, it seems like what you where expecting was not design to work. Best I can do is a feature request report. However, the part about 200 error code seems “logical”, since usually REST response will embed record/records as a response as a usual 200 response.
status 500 however indeed does not share the same format as smart action. I do agree that this is weird though. The bonus “choose color of the toastr” is, as well, in the feature request report.

This is the best solution I can provide for now. This is far from being ideal, but that’s the best I can do.

Let me know if that helps :pray:

1 Like

Hey :slight_smile:

Thanks for this detailed answer and thanks for all of your help :slight_smile: I will then try to keep an eye on this thread and wait on your return.

For now, I guess we will keep on checking logs to understand what happens (on fail mostly, smart actions)

Thanks again :slight_smile:

Max