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).
Related
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.
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.
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
Getting into CQRS and I understand that you have commands (app layer) and events (from the domain).
In the simple case where events are to update the read model, do read model updates fail? If there is no "bug" then I cannot see them failing and as I am using EventStore, I know there is a commit flag which will retry failures.
So my question is do I have to do anything in addition to EventStore to handle failures?
Coming from a world where you do everything in one transaction and now things are done separately is worrying me.
Of course there may be cases where a published event will fail in the read models.
You have to make sure you can detect that and solve it.
The nice thing is that you can replay all the events again and again so you have the chance not only to fix the error. You can also test the fix by replaying every single event if you want.
I use NServiceBus as my publishing mechanism which allows me to use an error queue. Using my other logging tools together with the error queue I can easily determine what happened since I have the error log and the actual message that caused the error in the first place.
In my Service Broker design, I need to make an asynchronous calls and needed some work to get done in background (Inside SQL Server only, like updating tables).
There are certain points to be taken under consideration based on the requirement :
It's kind of one-way data push. Just place a message into the SB queue and forget. No acknowledgement required.
Only one database involved in the design. There is no need for multiple databases.
Message will be placed to the SB queue using a Stored Proc ( This SP will be called by an application).
By observing above points, it seems that requirement doesn't suits for creating 2 different SB services as only one service would suffice. I designed the scenario with having only one SB Service, and while creating a conversation dialog, I assigned same service name to the 'From' & 'To' clauses. Program pushes data to the SB queue and activator will activate associated Store Procedure.. It works just fine.
BEGIN DIALOG CONVERSATION #RecordConversationHandle
FROM SERVICE **UpdateQueueStatus**
TO SERVICE '**UpdateQueueStatus**'
WITH ENCRYPTION = OFF;
Please help me by any suggestion on the above proposed design.. ? Any suggestions/issues or anything which demands attention to improve the design for better performance & scalability would be much appreciated.
Service broker is designed for dialogs, not monolog conversations. Don't design something new (There is tons of good reasons why they are always dialogs)
You can create sending service (Service1), witch is used for sending messages and receives "End Dialog" messages and ends dialog. The other (Service2) witch receives messages and does some processing with them + ends dialog when work is done.
The main reason of two services in a dialog and dialog-oriented conversations is the ability to disable queue. The initiator's queue may be enabled while at the same time, for some purpose or reasons, the target's queue may be disabled. In this case, sedning messages runs without the "disabled queue" error and messages will wait in the transmition queue until the target queue become enabled again.
That is why a contract may contain just one message type, and a queue may be created without specifying any contract. It's the initiator's queue.
There is a caveat: BEGIN CONVERSATION TIMER. It puts the standard message https://schemas.microsoft.com/SQL/ServiceBroker/DialogTimer into a local queue the specified conversation dialog belongs to.
One use case when a dialog on the same service may be usefull, is a recovery process. However, in this case, there should be a specific message type received in a higher priority than ordinary messages. The activation procedure first receives a recovery message, tries to recover, rollback if unsuccessfull, then receives an ordinary messages and commits receiving messages of both the types or just rollback if unsuccessfull again.