Sentry is alerting duplicate errors on every deploy - sentry

Currently, Sentry is alerting of the same issue on every deployment. How can I modify this setting to have a sentry alert in some time interval?
for example: if the error is appearing more frequently, then alert in an interval of time rather than wait for the next deployment and then alert about it.
thanks for your help.

Related

Queue Clean After Power Automate Queue triggers finished

I have a Power automate Flow which triggers when there is a message in azure queue and process the message. Power automate triggers perfectly when there is a item in queue. But after successful process , Message is returning back to the queue. And again getting trigger by power automate. Is there any settings I have to change ?
Can someone help ?
After reproducing from my end, I faced the same issue. To resolve this, one way you can do is to add another action called Delete message (V2) specifying the required properties in the end. Below is the flow of my logic app.

How to design notification system that sends real-time alerts created by users

I've been thinking about how to design a system that supports user created scheduled alerts. My problem is once the alerts are created and inserted into a database, I don't know what the best way to go about scheduling those alerts. Polling the database to see which alerts need to go out next doesn't seem entirely right to me.
What are some ways this could be handled on a scale where say a million users could create their own custom alerts like change baby diaper at 3pm everyday?
This problem is very suitable for cloud platforms. For example, you could use GCP Cloud Scheduler to invoke a cloud function when the alert is supposed to be sent out. The cloud function then calls some API to alert the user.
If cloud platforms are not an option, you could have your application spawn a new thread when an alert is created, and sleep that thread for a certain duration. When it wakes up, it sends the alert. Less elegant and less scalable than the first solution, but it would still work.

autofetch date in slack workflow

I am creating a simple workflow(No coding yet) with a scheduled timer that will send a message in a Slack channel every day at 5 AM UTC. I want the Message to auto picks up the date while sending the message. Is it possible?
As far as I can tell, you can not do so without coding an implementation.
When setting up messages as a workflow step using the basic slack-provided option, the only variables you can insert in the message are references to the channel where the workflow is being executed and to the user executing the workflow.
Coding up a workflow step is not particularly challenging though, so take a look at the slack documentation here for a guide on how to approach it.

How reliable is delaying a Mail in Laravel?

I want to inform the seller, that the buyer is coming soon (about 2 hours before pickup time) via mail.
I would normally do it the hard way with CRON and a database table. Checking hourly if I find an order with pickup time minus 2 hours, only then sending the mail out.
Now, I would like to know if you would recommend using Queueing Jobs for sending Mails out.
With
$when = now()->addDays(10); //I would dynamically set the date
Mail::to($order->seller())
->later($when, new BuyerIsComing($order));
I can delay the delivery of a queued email message.
But how safe would this be? Especially, if someone is ordering something but is picking it up in let us exaggerate two months?
Is the Laravel queueing system rigid enough to behave correctly after long delays (i.e. 2 months)?
Edit
I'm using Redis for Queueing
You actually have nothing to worry about. Sending mail usually increases the response time of your application, so it's a good thing you want to delay the sending.
Queues are the way to go and it's pretty easy to setup in Laravel. Laravel supports a couple of them out of the box. I would advise you start with database and then try beanstalk etc.
Lastly and somehow more importantly, use a process manager like Supervisor to monitor and maintain your queue workers...
Take a look at https://laravel.com/docs/5.7/queues for more insight.
Cheers.
If by safe, you mean reliable, then it would be little different than sending an email immediately. If there's ever a possibility that your server "hiccups" and doesn't send an email, that possibility would be the same now as 10 minutes from now. Once the job is in the queue, it is persisted until completion (unless you use a memory-based driver, like Redis, which could get reset if the server reboots).
If you are using a database queue driver or remote, the log of queued jobs will remain even if the server is unavailable for a short period of time. Your queue will be honored even if the exact time stamp for when you want to send the job has expired. For instance if you schedule to send an email at 1:00pm but your server is down at that exact moment, when it comes back online it will still see the job because it is stored as incomplete and the time for the job is in the past, which will trigger the execution of the job at the next time your queue worker checks the job list.
Of course, this assumes that you have your queue worker set up to always check jobs and automatically restart, even after a server failure, but that's a different discussion with lots of solutions...such as those shown here.
If you're using database driver with Laravel queues to process your email then you don't need to worry about anything.
Jobs are only removed from Jobs table if they are successfully completed otherwise their next attempt time is set which is few minutes in future and they are executed again (if your queue worker is online).
So its completely safe to use Laravel queues

spring activemq jmsTemplate.setTimeToLive take longer time more than the specified miliseconds to delete the message

i need to delete a message after specific time so i enabled the explicitQosEnabled and set the time to live.
but i noticed that the message is deleted but it takes longer time than the specified(one minute) so anyone faced this issue before?
Its working as expected. I don't see any issues. If you are using activeMQ can you open your message and see the expiration of the message through the browser. The expiration should have the exact epoch timestamp when the message will expire. You can also use API to jmsTemplate.getTimeToLive on your message.
Gubs

Resources