Skip to main content
Contributor ⭐️⭐️⭐️
August 19, 2026
Solved

Why does aborting a rule not abort?

  • August 19, 2026
  • 4 replies
  • 156 views

When we have a rule queued and try to abort it, nothing happens. It’s like the abort itself gets placed in the queue… While that is waiting to abort, any new executions (triggers from S3 upload) are still skipped because it sees that aborted run as still in queue. This doesn’t make sense; aborting something should be immediate. I’ve never seen this behavior anywhere else and it’s becoming an issue today.

Best answer by Prabhakar Puligadda

Hi ​@ndollimo_bt 

When a Rule execution is queued, initiating an Abort is not instantaneous. The Abort request needs to be processed by downstream services before the original execution can be fully cleared.

While the Abort is being processed, the original execution continues to be considered active. Since a Rule can only have one active execution at a time, any new trigger during this period, including an S3 upload, will remain queued until the previous execution has been fully aborted.

Once the Abort is completed and the original execution is marked as Aborted, the existing execution is cleared and the next execution can proceed normally.

So, the behavior you're seeing is due to the time required to complete the Abort rather than the Abort request being permanently queued or ignored.

 

Thankyou!

4 replies

alizee
VIP ⭐️⭐️⭐️⭐️⭐️
August 21, 2026

Hi ​@ndollimo_bt 

It does abort but as you noticed it sometimes takes a while.

My suggestion would be to log your question as an idea so we can upvote your request for a change in behavior.

Thanks

A

The most expensive part of building is the mistakes. That's true in construction. Not so much in CSOps. So ask questions, make mistakes and learn. All views expressed here are my own.
Prabhakar Puligadda
Gainsight Employee ⭐️
Gainsight Employee ⭐️
August 21, 2026

Hi ​@ndollimo_bt 

When a Rule execution is queued, initiating an Abort is not instantaneous. The Abort request needs to be processed by downstream services before the original execution can be fully cleared.

While the Abort is being processed, the original execution continues to be considered active. Since a Rule can only have one active execution at a time, any new trigger during this period, including an S3 upload, will remain queued until the previous execution has been fully aborted.

Once the Abort is completed and the original execution is marked as Aborted, the existing execution is cleared and the next execution can proceed normally.

So, the behavior you're seeing is due to the time required to complete the Abort rather than the Abort request being permanently queued or ignored.

 

Thankyou!

Contributor ⭐️⭐️⭐️
August 24, 2026

Thanks Prabhaka!

That does explain it, though I’ll be honest, I don’t like it lol. It was a good 45 minutes for the rule to abort before we could continue with our work on it which put a pretty good damper on things. Do you know if there any plans to optimize that process so aborting a rule could abort much sooner?

Prabhakar Puligadda
Gainsight Employee ⭐️
Gainsight Employee ⭐️
September 1, 2026

Thanks for the additional context.At this time, we don’t have an optimization for abort processing planned for Q3. Since abort duration can vary depending on the underlying processing, the team is first trying to determine whether this was an isolated occurrence or a recurring issue. If you see this behavior again, please raise a Support ticket with the approximate start time, rule name, execution details, and the time taken for the abort to complete. This will help the team investigate the pattern and assess whether further optimization is needed.