- Issue created by @phenaproxima
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
Without this, figuring out what actually happened on real sites would be impossible. Bumping to .
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
This came up again at #3351895-13: Add command to allow running cron updates via console and by a separate user, for defense-in-depth → .
Pulling into sprint.
- Assigned to yash.rode
- Open on Drupal.org →Core: 10.1.x + Environment: PHP 8.1 & MySQL 8last update
over 1 year ago Not currently mergeable. - @yashrode opened merge request.
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
No commits yet in >36 hours. Everything going okay here, @yash.rode?
- last update
over 1 year ago Custom Commands Failed - 🇮🇳India yash.rode pune
I was wrong yesterday that PreDestroyEvent exception is not logged but the case is both PreDestroyEvent and PostDestroyEvent Exceptions are not getting logged, I tried debugging it, as we don't know where exactly the error messages are getting logged I could not find it why it is happening.
- last update
over 1 year ago 746 pass, 1 fail - last update
over 1 year ago 746 pass, 1 fail - Status changed to Needs work
over 1 year ago 5:44pm 1 May 2023 - 🇺🇸United States tedbow Ithaca, NY, USA
In the quote from @Wim Leers in the summary we have
Otherwise post-mortems in the real-world (where updates will be installed automatically, and hence no user will be present to witness the error)
but in the suggested solution it says we should change
UpdateErrorTest::testExceptionFromEventSubscriber(),
which doesn't exist anymore since [##3354325] but was a functional that test what happens when the user does the update manually so won't cover "no user will be present "Also the current MR changes
src/BatchProcessor.php
which also won't affect cron updates.This is another example of why we should not make issues that simply quote another issue as the "Problem/Motivation" because is unclear unless you really dig in the other issue what the scope of the problem to be addressed is.
- 🇺🇸United States phenaproxima Massachusetts
@tedbow, to me this was perfectly clear. If an exception occurs from an event subscriber during batch processing, we want to be sure the exception and its backtrace are logged. Although the issue summary refers to a non-existent method, the gist is still correct, and what we're trying to implement. What's the problem here?
- 🇺🇸United States tedbow Ithaca, NY, USA
re #10
If an exception occurs from an event subscriber during batch processing
but the quote from the issue summary says
Otherwise post-mortems in the real-world (where updates will be installed automatically, and hence no user will be present to witness the error) will become impossible.
(emphasis mine)
If "no user will be present to witness the error" then we are talking about cron updates, cron updates do not use "batch processing"
- last update
over 1 year ago 746 pass, 1 fail - Issue was unassigned.
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
@tedbow's point in #11 is fair, since apparently cron vs UI (non-cron) updates have different execution flow.
The real point here though is that exceptions should ALWAYS be logged, regardless of cron vs UI updates! And #11 may be correct in quoting what I said literally but is sort of ignoring the spirit: we cannot expect end users to meticulously take notes of everything they see happen. No matter whether that's during cron updates (where they CANNOT see it) or UI updates (where they COULD see it).
However … it's shocking news to me that cron updates and non-cron updates apparently do not use the exact same logic! 😳 It never even occurred to me that they'd be implemented differently. The stage life cycle is the same, only the way things get executed is different.
We need to document why these are implemented so differently. Why is it for UI-based installing of updates not okay to assume the entire stage life cycle finishes within a single request, but for cron-based installing of updates it is okay? 🤔
Unassigning @yash.rode, because @tedbow and @phenaproxima need to clarify this. We also need a follow-up issue that only either of them can work on to document the architectural differences between cron vs non-cron updates.
- 🇺🇸United States tedbow Ithaca, NY, USA
The real point here though is that exceptions should ALWAYS be logged, regardless of cron vs UI updates! And #11 may be correct in quoting what I said literally but is sort of ignoring the spirit:
I agree. This should have been state in the summary more clearly. I don't think we should be making issues and handing them off to others follow the "spirit" of the issue.
Why is it for UI-based installing of updates not okay to assume the entire stage life cycle finishes within a single request, but for cron-based installing of updates it is okay?
- Cron sets a long time limit to be able to do more operations. We could do this in the UI but then user has no feedback for the entire cycle.
- The batch system gives the user feedback that something is happening so they don't have to wait and see nothing for whole cycle.
- After the update is staged and before it is applied in UI we are able to show the user the form with the "Continue". Here we can show them more relevant information about what was staged. Currently I think all we are showing them is the message about possible database updates from
StagedDBUpdateValidator
but this is very important information and the user may decide not to run an update that has staged database updates(to run it at another time). Other contrib or custom code also follow this same pattern of listening to StatusCheckEvent and if there is staged update show some warning if it is not cron and an error if it is cron.In cron updates we don't allow updates to run if there are staged database updates. There wouldn't be anybody to show this information to anyways.
- 🇺🇸United States tedbow Ithaca, NY, USA
Created a follow-up 📌 [META] Update doc comment on BatchProcessor to specify why use the batch system Active
- Assigned to omkar.podey
- Assigned to tedbow
- 🇮🇳India omkar.podey
So is the conclusion that cron sets a longer time hence can be assumed that it happens in a single request so this should be only done for cron and not for the UI updates ?, can you update the issue summary so it's more clear what the next steps are.
- Assigned to omkar.podey
- 🇺🇸United States tedbow Ithaca, NY, USA
@omkar.podey I have update the summary. I think this is actionable now
The issue will not be affect by 📌 For web server dependent unattended updates run the entire life cycle in a separate process that will not be affected by hosting time limits Fixed
- last update
over 1 year ago 811 pass - last update
over 1 year ago 811 pass - last update
over 1 year ago Custom Commands Failed - last update
over 1 year ago 819 pass - last update
over 1 year ago 819 pass - Issue was unassigned.
- Status changed to Needs review
over 1 year ago 7:58am 29 June 2023 - Assigned to omkar.podey
- Status changed to Needs work
over 1 year ago 9:08am 3 July 2023 - last update
over 1 year ago 819 pass - last update
over 1 year ago 819 pass - last update
over 1 year ago 819 pass - Issue was unassigned.
- Status changed to Needs review
over 1 year ago 7:30am 4 July 2023 - last update
over 1 year ago 819 pass - Assigned to omkar.podey
- Status changed to Needs work
over 1 year ago 9:52am 5 July 2023 - last update
over 1 year ago 819 pass - Issue was unassigned.
- Status changed to Needs review
over 1 year ago 11:25am 5 July 2023 - 🇮🇳India omkar.podey
@Wim.leers I was trying to think of a way to test the back trace as i'm currently logging it as context. do you think that's necessary ?
- Assigned to phenaproxima
- 🇺🇸United States phenaproxima Massachusetts
Self-assigning for review.
- Issue was unassigned.
- Status changed to Needs work
over 1 year ago 1:45pm 5 July 2023 - 🇺🇸United States phenaproxima Massachusetts
This seems like a reasonable start, but there are some aspects that feel...porous to me. Maybe I'm missing something, though. In general I think we need better comments.
- Assigned to omkar.podey
- last update
over 1 year ago 741 pass, 3 fail - last update
over 1 year ago 742 pass, 2 fail - last update
over 1 year ago 742 pass, 2 fail - last update
over 1 year ago 778 pass, 1 fail - last update
over 1 year ago 819 pass - Issue was unassigned.
- Status changed to Needs review
over 1 year ago 12:46pm 6 July 2023 - Assigned to tedbow
- Issue was unassigned.
- Status changed to Needs work
over 1 year ago 5:08pm 6 July 2023 - 🇺🇸United States tedbow Ithaca, NY, USA
Looking good. Just a few more things
- last update
over 1 year ago 819 pass - Assigned to omkar.podey
- last update
over 1 year ago 402 pass, 38 fail - last update
over 1 year ago 819 pass - last update
over 1 year ago 819 pass 36:00 35:18 Running- last update
over 1 year ago 819 pass - Issue was unassigned.
- Status changed to Needs review
over 1 year ago 11:19am 10 July 2023 - Status changed to Needs work
about 1 year ago 6:55pm 26 October 2023 - 🇺🇸United States tedbow Ithaca, NY, USA
Needs to be merged/rebased with 3.0.x
- last update
about 1 year ago Custom Commands Failed - last update
about 1 year ago Custom Commands Failed - last update
about 1 year ago Custom Commands Failed - last update
about 1 year ago 734 pass, 4 fail - last update
about 1 year ago 734 pass, 4 fail - last update
about 1 year ago 777 pass - Assigned to tedbow
- Status changed to Needs review
about 1 year ago 3:13am 2 November 2023 - Assigned to phenaproxima
- Status changed to Needs work
about 1 year ago 1:40pm 2 November 2023 - last update
about 1 year ago 777 pass - Assigned to tedbow
- Status changed to Needs review
about 1 year ago 1:50pm 2 November 2023 - Issue was unassigned.
- Status changed to RTBC
about 1 year ago 2:00pm 2 November 2023 - last update
about 1 year ago 777 pass - last update
about 1 year ago 777 pass - last update
about 1 year ago 777 pass -
phenaproxima →
committed 4400bebd on 3.0.x authored by
yash.rode →
Issue #3354701 by omkar.podey, phenaproxima, yash.rode, tedbow, Wim...
-
phenaproxima →
committed 4400bebd on 3.0.x authored by
yash.rode →
- Status changed to Fixed
about 1 year ago 2:41pm 2 November 2023 Automatically closed - issue fixed for 2 weeks with no activity.