# Rate limiter less than a second?

**URL:** <https://discourse.nodered.org/t/rate-limiter-less-than-a-second/84277>\
**Category:** General\
**Created:** [4 January 2024 09:27 UTC](https://discourse.nodered.org/t/rate-limiter-less-than-a-second/84277 "2024-01-04T09:27:09Z")\
**Posts on this page:** 1\
**Showing post:** 15

<div class="post-metadata">

**Author:** ![kuema](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/kuema/32/6542_2.png) [@kuema](https://discourse.nodered.org/u/kuema)\
**Post date:** [8 January 2024 14:21 UTC](https://discourse.nodered.org/t/rate-limiter-less-than-a-second/84277/15 "2024-01-08T14:21:21Z")

</div>

Oh boy, I'm getting old. 🥴

I have already mumbled my exact thoughts on the matter in the topic you mentioned, which is using the `.error` property... 🙈

> [@Capturing errors caused inside link-call flows](https://discourse.nodered.org/t/capturing-errors-caused-inside-link-call-flows/80010/9):
>
> Using the .error property as indicator is the only way right now. The link return doesn't (and shouldn't) know anything about the nodes connected, that would make it much more complex. I think it should only react on the message. I think of .error as a convention for errors, just like payload for data. I actually use it that way sometimes to generate an error that is not from a catch node, so I can use the same error handling flow path. In some of my own nodes (request-response paradigm) I us…

And I realize (again), that there's no trivial solution to it, either.

---

_[View the full topic](https://discourse.nodered.org/t/rate-limiter-less-than-a-second/84277)._
