[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: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| 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. 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. |
| Comment by Jan Haderka [ 04/Aug/15 ] |
|
Due to complexity described here and in related story - |