[MGNLUI-3107] Publishing deletion right after delete can result in exception Created: 18/Aug/14  Updated: 18/Aug/15  Resolved: 04/Aug/15

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Daniel Lipp Assignee: Mikaël Geljić
Resolution: Won't Fix Votes: 0
Labels: asynch-issue, support, unizh
Remaining Estimate: 3d
Time Spent: Not Specified
Original Estimate: 3d

Attachments: PDF File [#UZH-779] Publish Delete sofort nach bzw. während Delete - Scheduler Error.pdf    
Issue Links:
relation
is related to MGNLACTIVATION-99 Unpublishing right after publication ... Closed
supersession
is superseded by MGNLUI-3398 Redesign action capabilities: multi-i... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Sprint: Sprint 2 (Basel)
Story Points: 8

 Description   

If you trigger a "publish deletion" action right after (or during) a "delete" action you might run into a scheduler error (tested with ee 5.2.8 + ee 5.3.2).



 Comments   
Comment by Evzen Fochr [ 21/Nov/14 ]

Maybe this is not a bug if there is some nice message "Another action is still in progress. Please try later."

Comment by Michael Mühlebach [ 23/Jan/15 ]

I could reproduce the exception reported from the customer but in a slitty different scenario: Delete and publish twice and approve the two publishes nearly at the same time. Then it can happen that the publish jobs overlap each other.
Usually if you publish a delete several times, with reasonable time between them, on the author instance you get an ItemNotFoundException, which is perfectly fine because this is what actually happens and we can not prevent this scenario.

In the scenario with the overlapping jobs the two publishes are sent to the public instance and a similar exception occurs there. This should not happen because the author instance should catch this already.

So long story short: the solution should be to serialise the job execution.

Comment by Mikaël Geljić [ 04/Aug/15 ]

After several re-iterations over this, it's unclear whether we can do a quick fix for this.
We acknowledge async action support is shaky, and we have to go through major changes to tame this. More details at MGNLUI-3398.
Meanwhile, we apologize for any inconvenience this may cause.

Comment by Jan Haderka [ 04/Aug/15 ]

Due to complexity described here and in related story - MGNLUI-3398, this problem unfortunately can't be solved without making more significant changes to the backhand and thus can't be solved in course of maintenance releases but will be instead tackled (in related separate story) as part on 5.5. release.

Generated at Mon Feb 12 09:03:17 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.