Errors in mailin don't abort the transaction

Bug #1375884 reported by Chris Rossi
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
KARL4
Confirmed
Medium
Unassigned

Bug Description

In testing mailin on staging I was able to corrupt the blog, a blog post was created and then exception was raise, and instead of rolling back the transaction, the transaction was committed, leading to a corrupt blog entry:

https://karlstaging.gocept.com/communities/a-time-for-testing-again/blog/might-as-well-test/

Changed in karl3:
importance: Undecided → High
status: New → In Progress
milestone: none → m140
assignee: nobody → Chris Rossi (chris-archimedeanco)
importance: High → Undecided
Revision history for this message
Chris Rossi (chris-archimedeanco) wrote :

Now that I look at this, this doesn't have to do with karlserveless. It's been latent in Karl for some time. Basically when we put messages in the quarantine, because they have an exception for some reason, we don't do anything to roll back the work that might have been done before we hit the exception. We don't want to abort the entire transaction, since that would defeat the point of moving messages to the quarantine. And, of course, moving messages to the quarantine is part of the transaction. It might make sense to start using savepoints, though, and roll back to a savepoint made before attempting to process a message, before moving the message to the quarantine. I've never been superclear how well savepoints work in ZODB. Will look into it.

Revision history for this message
Paul Everitt (paul-agendaless) wrote : Re: [Bug 1375884] Re: Errors in mailin don't abort the transaction

Very good job on the diagnosis.

--Paul

On Sep 30, 2014, at 4:09 PM, Chris Rossi <email address hidden> wrote:

> Now that I look at this, this doesn't have to do with karlserveless.
> It's been latent in Karl for some time. Basically when we put messages
> in the quarantine, because they have an exception for some reason, we
> don't do anything to roll back the work that might have been done before
> we hit the exception. We don't want to abort the entire transaction,
> since that would defeat the point of moving messages to the quarantine.
> And, of course, moving messages to the quarantine is part of the
> transaction. It might make sense to start using savepoints, though, and
> roll back to a savepoint made before attempting to process a message,
> before moving the message to the quarantine. I've never been superclear
> how well savepoints work in ZODB. Will look into it.
>
> --
> You received this bug notification because you are subscribed to KARL3.
> https://bugs.launchpad.net/bugs/1375884
>
> Title:
> Errors in mailin don't abort the transaction
>
> Status in KARL3:
> In Progress
>
> Bug description:
> In testing mailin on staging I was able to corrupt the blog, a blog
> post was created and then exception was raise, and instead of rolling
> back the transaction, the transaction was committed, leading to a
> corrupt blog entry:
>
> https://karlstaging.gocept.com/communities/a-time-for-testing-
> again/blog/might-as-well-test/
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl3/+bug/1375884/+subscriptions

Changed in karl3:
status: In Progress → Confirmed
Changed in karl3:
importance: Undecided → Medium
milestone: m140 → m141
Revision history for this message
Paul Everitt (paul-agendaless) wrote :

I'm going to move this out of the way for now. I'd like us to wrap up some of the KARL4 ideas while we're in the mode of cleanup.

Changed in karl3:
milestone: m141 → m142
affects: karl3 → karl4
Changed in karl4:
milestone: m142 → none
Changed in karl4:
milestone: none → 002
Changed in karl4:
milestone: 002 → 003
Changed in karl4:
milestone: 003 → 004
Changed in karl4:
milestone: 004 → 005
Changed in karl4:
milestone: 005 → 999
assignee: Chris Rossi (chris-archimedeanco) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.