I have followed the instructions available at https://github.com/airbrake/airbrake-js to allow for JS exceptions to be farmed out to Airbrake.
What I am wondering is - is there a way to intercept these exceptions BEFORE that are sent to Airbrake? I want to limit messages sent over the wire to Airbrake as it's not looking to good in the console when we start getting MANY 503 responses with the old message of "You've performed too many requests"
We're currently re-writing our Javascript notifier. This will be one of the features of the updated notifier. Watch this space.
Ben
Related
I've come across a strange issue with the Slack API/Bolt library, whereby listeners which work when triggered by genuine messages (i.e. sent via the Slack GUI) trigger these events with no issues, but messages which should trigger the listener that are sent through code work only very sporadically (maybe once eveery 10-15 times, usually a bit more after you've re-installed your app to the workspace).
The below code is an example listener:
#bolt_app.message("test")
def test_funct(message, say):
say("found")
The following is an example snippet to produce a message which meets the criteria:
client.chat_postMessage(
channel="#test-channel",
text="test"
)
I've tried using an alias for bot when sending, but no notable difference. Permissions all check out according to the documentation. It's also worth noting that the client configuration is the same for both (we're using the same app and the same tokens etc).
I am trying to subscribe to a salesforce channel, I was able to get the messages from the channel.
But the issue is I am getting the messages one after another, the expected way of receiving is when bulk messages are published to the channel. Need to get the messages as a whole in the subscriber.
Let's say if I publish 500 messages, I need to get whole 500 messages here on the subscriber. But I am getting one message after another.
I am using the following code
async with client:
for topic in get_topics(system='salesforce'):
await client.subscribe(topic)
async for message in client:
messages = message
The above code is called inside async function
I am not sure this a bug from library or the method I follow is wrong
please let me know what is the issue.
I was able to figure out this Issue,
It is not related to library, it is super awesome. I was able to get the message real time.
The issue was with the architecture I have currently, which is causing the delay.
Thank you all for the help.
I see like it is not so good to answer this way, but answering it so that it might give someone heads up. While looking for such errors.
They can easily start debug the architecture instead of the library.
Here's the code:
How to ensure the javascripts/channels/chatrooms.coffee is loading and receive: (data) works? Console.log data is not loading
I posted the problem the other day. It comes from a tutorial, but somewhere after continuing work on my project, I'm not sure where the bug came up,
But the message relay job posts on the server, and my config.yml has redis with redis up and running.
There have been similar bugs, but I've worked through those solutions and it's not enough. The received: (data) console log doesn't arrive in the js console of the browser.
The App subscriptions seem to all be in order according to the tutorial, I bet it's a really simple fix.
My messaging system still works, so it's not crucial to the project, but it's a difference of having the chat system work in realtime versus with a 4 second page-refresh delay.
The last problem I had was not including jquery for my other coffeescripts, so I'm guessing the channels coffeescripts is probably a one line fix.
For the google actions that i am developing some responses are complex and take more than 5 seconds to process.
Could someone please suggest how can this be handled.
Generally i would consider using loading dots and then replacing that message with the result but i don't see any Google Action API for it. Also is there any endpoint to which we could async send back the result later ?
Thanks
PS: I am using Conversation API.
We don't really have a good way to handle this right now, but we have a couple of approaches that sorta work based on your needs.
Notifications are currently available for the Assistant on smartphones, and they're coming for speakers. In some cases, it might make sense to say that you're working on the problem and you'll send a notification when you have it, and then resume the conversation from the notification.
Another approach is to use the Media Response to play a bit of "hold music". At the end of the segment of music, your webhook will get a notice that the music has completed. If you have the result available, you can report it at that time.
My program needs to react to the user not taking any action on a GNotification.
More specificially, a piece of data is written to the database only if the user does not press the "undo" button on the notification sent after the data's creation. My target deployment scenario does have notifications enabled and a real timeout value.
To be precise: Moving the notification "away" / deleting it should also count as such a timeout.
1) Is there a built-in way to 'listen' to notification timeouts?
2) If not, how could I still implement similar behavior?
I would use the D-Bus org.freedesktop.Notifications interface. Although it is still a draft specification, it does appear stable. My experience accessing the D-Bus interface using Vala has been that it is easier to use and gives the full feature set of the specification. GNotification doesn't seem to be as feature complete.
From the draft specification you will see there is an expire_timeout argument of the org.freedesktop.Notifications.Notify method. That should fit your time out requirement, although I've not used it personally. There is also a org.freedesktop.Notifications.NotificationClosed signal that will allow your program to be notified when the notification is closed, including because of a time out or if it was dismissed by the user.
This post about the screen lock re-design for GNOME Shell 3.10 might give some indication of what notifications are capable of. The post includes some screenshots of notifications appearing in the lock screen.