Problem/Motivation
While updating from 8.5.6 to 8.6.0/8.6.1, taxonomy_update_8502 entered an infinite loop and was never completed. On aborting the update and re-running, an integrity constraint violation error was thrown as the first term had already been migrated.
[notice] Update started: taxonomy_update_8502
[error] SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1-0-0-nl' for key 'PRIMARY': INSERT INTO {taxonomy_term__parent}
The infinite loop occurs when the taxonomy_term_hierarchy
table refers to records that no longer exist in taxonomy_term_data
for some reason.
Proposed resolution
Ensure that orphan records are excluded from the total count, thus allowing the update function to correctly determine that all taxonomy_term_hierarchy
valid records were migrated.
User interface changes
None
API changes
None
Data model changes
None
Original report
While updating from 8.5.6 to 8.6.0 the following error was raised during the database update:
[notice] Update started: taxonomy_update_8502
[error] SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1-0-0-nl' for key 'PRIMARY': INSERT INTO {taxonomy_term__parent}
The website where the update was run is fairly simple: only 2 custom taxonomies, each with about 5 terms, no hierarchy.
The codebase was updated with composer, then db updates were run with drush, but the same issue happens with update.php.
Comment | File | Size | Author |
---|---|---|---|
#88 | 2997982_truncate_taxonomy_term__parent_table_2.patch | 519 bytes | ueshiy |
#73 | 2997982_truncate_taxonomy_term__parent_table.patch | 487 bytes | woutervu |
#45 | 2997982-45.patch | 1.45 KB | longwave |
#45 | 2997982-45-test-only.patch | 628 bytes | longwave |
|
Comments
Comment #2
cilefen CreditAttribution: cilefen as a volunteer commentedComment #3
plachWould you be able/allowed to share a sanitized/anonymized DB dump? Ideally a pre-update backup.
Comment #4
plachCan you try the patch at #2997960-9: Missing taxonomy hierarchy items in 8.6.0 after running taxonomy_update_8502?
Comment #5
longwaveOne issue I can see in the update hook is that we might reuse deltas if two terms from the same parent arrive in different batches:
$tid is reset on every batch, so if a previous batch saw the same term ID, we will try to insert delta 0 again.
Comment #6
longwaveI think we can prove this in the existing test.
Comment #7
longwaveAnd the fix.
No guarantee of course that this is the original issue, as that sounds like it might be different, especially if the site has less than 100 terms as they should all be processed in one go?
Comment #9
plachFancy!
This definitely looks like an improvement, however I agree this is unlikely to fix the issue reported here, since we are dealing with only 5 terms. It might be useful to fix #2997960: Missing taxonomy hierarchy items in 8.6.0 after running taxonomy_update_8502 though. Worth posting over there IMO.
Comment #10
longwaveBack to the original report, "Duplicate entry '1-0-0-nl'" feels like this could be the very first row, and so perhaps the update hook has already (partially?) run somehow? Should we truncate the destination table at the start of the first batch, just in case?
Comment #11
plachIf the update is really running twice, we should find out what's going on and fix the root cause, otherwise we might be just hiding a bug
taxonomy_update_8502
is uncovering. AFAICT the only way this could be running twice is thattaxonomy_update_8502
failed previously, so I guess we would need to know which the original error was.It would be also good to know whether this is a multilingual site.
In any case, I think we need several inputs from @samuhe before being able to investigate further :)
Comment #12
bzrudi71 CreditAttribution: bzrudi71 as a volunteer commentedSame error here. I tried to upgrade to 8.6.0 from the latest 8.5 and got DB errors during upgrade on a dev box. This is what I get with PostgreSQL and drush. The site has around 40.000 taxonomy tags so the update seems to run in batches.
I will rerun and investigate on Monday.
Comment #13
longwave@bzrudi71 That looks like it could be the issue I spotted - can you try with the patch from #7 and see if that fixes it?
Comment #14
chaz.chumley CreditAttribution: chaz.chumley commentedI am running into same issue here. I have over 70,000 terms in database. I have had to increase the memory limit to 2048M just to get past a allowed memory issue to run this update. I have had to truncate the taxonomy_term_parent table each time before running the update. Now it is failing with - error: Invalid string length.
I used the patch above but same error.
Since I assume there will be a lot of real world users that have older D8 sites with a lot of content that they too will run into this issue. Seems to me that Core maintainers didn't truly test this before releasing 8.6 to the world.
Please advise how to fix this or when a proper patch or update will be available.
Comment #15
bzrudi71 CreditAttribution: bzrudi71 as a volunteer commentedJust back from vacation I spend some minutes reading the 8002 taxonomy update code. My guess is the problem is because of a missing orderBy() clause in the select for the hierarchy relation. When doing a select without an order by condition the order is not guaranteed and may cause this issue. Drupal should really throw an exception in case of a select without an order condition ;)
Anyway, I'm back in Office tomorrow and will check and report...
Update: Just discovered related issue #2997960: Missing taxonomy hierarchy items in 8.6.0 after running taxonomy_update_8502. Looks like the right approach to me and should fix this issue as well. Will report results over there...
Comment #16
plach@chaz.chumley:
You should probably test the patch available at #2997960: Missing taxonomy hierarchy items in 8.6.0 after running taxonomy_update_8502, but could you provide more details about the
error: Invalid string length.
error? Is it an exception triggered while runningtaxonomy_update_8502()
? Could you post the full message/stack trace?This is a bold assumption and something very unfair to say. The issues we identified so far were not reliably reproducible or were edge cases, so it is entirely possible that the people that worked on the original issue manually tested the update code without discovering them. And even if you were right, it's not clear to me what's the goal of such a comment, besides blaming the people you're asking support from. There were a lot of 8.6 development releases before 8.6.0 (alpha, beta, RC) that people could have exploited to test the upgrade and report any issues, which would have benefitted everyone in the community much more than complaining about how broken the stable release is.
Comment #17
plachMost of the issues we identified so far should be addressed by #2997960: Missing taxonomy hierarchy items in 8.6.0 after running taxonomy_update_8502. I'm going to rescope this to specifically figure out what happened in the originally reported case. @longwave and I currently assume that the update function was run twice. To figure out what happened we definitely need more info, I'll update the IS accordingly.
Comment #18
plachIS updated
Comment #19
bzrudi71 CreditAttribution: bzrudi71 as a volunteer commentedPatch in #2997960: Missing taxonomy hierarchy items in 8.6.0 after running taxonomy_update_8502 works for me. Thanks!
Comment #20
longwaveRemoved, commented on wrong thread
Comment #21
samuhe CreditAttribution: samuhe as a volunteer commented@Plach, yes i executed the update script multiple times. It could indeed have been an other error the first time.
Sorry, bit busy at the moment on another site. I will try to investigate further at the end of this week.
Comment #22
plachThanks, here's another report that's similar to what @samuhe experienced: #2997960-51: Missing taxonomy hierarchy items in 8.6.0 after running taxonomy_update_8502.
Comment #23
johns996 CreditAttribution: johns996 commentedI ran into this issue when updating to 8.6.1 from 8.5.3 using composer and drush. The first time the update ran drush kept printing out the same line in a loop until I killed it.
After killing it and running the update again it would fail with the following log message:
Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '19-0-0-en' for key 'PRIMARY': INSERT INTO {taxonomy_term__parent} (bundle, entity_id, revision_id, langcode, delta, parent_target_id) ...
The only way I could figure to get this to run was to truncate the taxonomy_term__parent table and then run the update again. After that the DB update ran smoothly and my site seems to be back up and running correctly.
Comment #24
bzrudi71 CreditAttribution: bzrudi71 as a volunteer commented@johns996 Why did you kill the update during the first run? The info line is printed as long as the taxonomy batch update is running, so for many terms the line may appear hundred of times and this is the normal behavior. Starting a second run will lead to this error and is also expected. So I see no real problem here. Just to make sure I run an update from 8.5 to 8.6.1 without any issue.
Comment #25
longwaveShould we file a bug against drush in that it doesn't report batch status very well? It could at least say "continuing" instead of "started" on the second line onwards.
Comment #26
johns996 CreditAttribution: johns996 commented@bzrudi71 I killed my terminal at 50,000 lines of
[notice] Update started: taxonomy_update_8502
. It seemed like a fairly safe bet that this was an out-of-control loop and not just a normal update. Especially since my site only has 100 nodes and 5 taxonomy terms.Full disclosure, when I ran the update the second time I didn't use drush and used the update.php script instead. The script only took a few seconds to complete as opposed to the few minutes I was stuck looking a the looping lines on the terminal during my first attempt.
I can roll everything back and try to reproduce the error again since I have a backup.
Comment #27
plachYes, please, steps to reproduce are cool :)
Comment #28
minnoce CreditAttribution: minnoce commentedI tried to update my Drupal 8.5.7 to 8.6.1 (from tar.gz package and via update.php admin interface), with 3 simple flat taxonomies (all with less than 10 terms) and I found the following error:
Comment #29
plachWas it the first time you attempted the update? Did you experience any error previously? Do you have a DB backup? Would you be able/allowed to share an export of your taxonomy_* tables?
Comment #30
catchIf you're restoring a backup to run the update, make sure you drop all database tables first. It's possible you're running the update into a table that already exists.
Comment #31
minnoce CreditAttribution: minnoce commentedI tried a new update, dropping first all DB tables and then restoring from a backup created with Drupal 8.5.6, just before the 8.5.7 update.
This time the update worked correctly, I believe. Here the final messages:
Comment #32
johns996 CreditAttribution: johns996 commentedI was able to reproduce the loop. He's the updates that Drush was about to run before the loop started:
things eventually died with an out-of-memory error
I backed up my taxonomy tables before I ran the update and put the dump in a gist.
https://gist.github.com/johns996/d76e0605bb28a9d2879e0c786342f2e1
Hopefully this helps.
Comment #33
johns996 CreditAttribution: johns996 commentedAfter testing a bit more with this issue, I discovered two things. After I run the update and have it loop and die, even if I truncate the taxonomy_term__parent table and run the updated again it still does the loop. Looking into my taxonomy_term_hierarchy table I see a row that does not line up with my other taxonomy tables:
Once I pull that row out, truncate the taxonomy_term__parent table and run the update again the loop does not happen and the update finishes.
Comment #34
longwaveWell spotted!
So, if for some reason there are orphaned records in taxonomy_term_hierarchy, $sandbox['max'] will count these, but the later query uses an inner join and will disregard the orphans, so the batch will never appear complete and this update will loop forever.
The attached patch fixes this by including the join in the count query. The orphaned records are useless and will be safely deleted at the end of the batch.
@johns996 Can you test this patch against your original database and let us know if it completes successfully?
Comment #35
catchSo this only happens with a bad data set, but since we don't know what's causing that bad data set in the first place or how many sites it affects yet, bumping to critical.
Comment #36
plachGreat catch!
Can we add a comment about why we are adding this?
Comment #37
idiaz.ronceroI'm experimenting the same issue, using a clean DB dump from my previous Drupal 8.5.7 install and I'm getting this error on drush updb
Failed: SQLSTATE[23000]: Integrity constraint violation: 1062 : INSERT INTO {taxonomy_term__parent}
The patch at #34 is not working for me.
Comment #38
longwave@idiaz.roncero When you restore the 8.5.7 database, are you sure that the taxonomy_term__parent table is being deleted? It should not exist in the dump, so simply restoring over the top will not work. If this is still failing with the table deleted, can you share your taxonomy_term_data and taxonomy_term_hierarchy tables?
Comment #39
johns996 CreditAttribution: johns996 commented@longwave Your patch worked perfectly against my original database and no loop was encountered.
Comment #40
plachCool, we just need some additional test coverage then (and maybe adding a comment to the new join line ;).
Comment #41
longwaveNot sure how an infinite loop will fare on the testbot, let's see.
Comment #42
longwaveHm, so that didn't do what I expected!
Comment #43
plachI don't think we need to reproduce the infinite loop, we just need to assert that the orphan was not migrated
Comment #44
effulgentsia CreditAttribution: effulgentsia at Acquia commentedI disagree. I think we need a test-only patch that includes an orphan and fails. And given HEAD's current code, when there's an orphan, the failure is that the batch never finishes. It's interesting that #41's test-only patch passes. I wonder why it does.
Comment #45
longwaveThe unexpected pass in #41 is a misunderstanding of the data structures in the test fixture, there are actually four terms created. This version seemed to loop forever when I ran it locally.
Comment #47
longwaveSpurious fail so I queued a retest
Comment #49
plachNice work!
Comment #50
plachComment #51
effulgentsia CreditAttribution: effulgentsia at Acquia commentedAdding issue credit to people who helped resolve the currently titled issue.
Comment #54
effulgentsia CreditAttribution: effulgentsia at Acquia commentedPushed to 8.7.x and 8.6.x. Thanks!
An issue summary update would still be great for future reference, if anyone feels up to writing it.
@idiaz.roncero: Re #37, I think you were running into #2997960: Missing taxonomy hierarchy items in 8.6.0 after running taxonomy_update_8502 rather than this issue. The patch there was committed and released in 8.6.1 before your comment though. Did you try with 8.6.1?
Comment #55
plachI believe the issue reported originally and by other people here was caused by the fact that the update was attempted multiple times without truncating the
taxonomy_term__parent
table in between attempts.Comment #56
longwaveIssue summary updated
Comment #57
longwaveComment #58
plachCrossposted with #56. Removed the following bit from the proposed solution as we did not implement it, and hopefully it's no longer needed now.
Comment #59
jibranAre we going to tag a new release?
Comment #60
plachNot my call, but I don't think so, this is not causing data loss AFAICT.
Comment #61
catchThis will go out no later than the October 3rd window whatever happens.
johns996 is as far as I can tell the only person who has confirmed orphaned records in taxonomy_hierarchy - the other reports here are not necessarily the same issue (some look like attempted repeat updates with the new database table not removed for example).
If we get further confirmed reports of sites hitting this issue with orphaned records, I could see releasing 8.6.2 out of cycle, but otherwise I think this can probably wait for October 3rd.
Comment #62
hellobank CreditAttribution: hellobank commentedI just upgraded from 8.5.x to 8.6.1. when I run the update.php, still got this kind of ERROR message. (See Attached)
Comment #63
hellobank CreditAttribution: hellobank commentedMaybe the Error is caused by the table name, I found there are two table name: "taxonomy_term_hierarchy" and "term_hierarchy".
the error message showed "taxonomy_term_hierarchy", but in my database, I see the table name is "term_hierarchy".
Comment #64
effulgentsia CreditAttribution: effulgentsia at Acquia commented@hellobank: thanks for reporting that.
Did you migrate your site from Drupal 6 directly, skipping Drupal 7, or did you go from 6 -> 7 -> 8? Also, what version of Drupal 8 did you initially migrate into?
Comment #65
hellobank CreditAttribution: hellobank commentedyes, migrated from D6 -〉D8 directly.
Not quite sure the initially migrate version, maybe 8.2.x.
Comment #66
filipposcarselli CreditAttribution: filipposcarselli commentedBefore migrate to 8.5,6 to 8.6.1 I have performed this two query on the database to delete orphans taxonomy_term_hierarchy record.
After that I have executed "drush up -y" and after some messageas "Performing taxonomy_update_8502" the update end.
I think thi is the best possible from this update.
Comment #67
aken.niels@gmail.comWhat I've done to restore our terms:
drush php-eval "\Drupal::database()->truncate('taxonomy_term__parent')->execute();"
drush php-eval "drupal_set_installed_schema_version('taxonomy', 8500)"
drush updb --entity-updates
Comment #68
XTaz#67 works for restore my terms, thanks.
PS: with drush php-eval "\Drupal::database()->truncate('taxonomy_term__parent')->execute();" (without the ")" at the end. )
Comment #69
patrick.thurmond@gmail.comSeems like it would be a good idea to have a patch that runs those two commands from #67. Maybe even patches the update that needs to re-run (according to that post). Though this seems a bit like a chicken vs egg conundrum.
Comment #70
Lukas von BlarerI created another issue regarding this update in case anyone is experiencing that as well: #3005162: taxonomy_update_8601 failing
Comment #71
CooleWampe CreditAttribution: CooleWampe commentedI haven't used drush yet. Isn't it possible to give a fast database hack insteed of "drush". Or refix it in the next version?
Comment #72
aken.niels@gmail.comIn response to #68, thanks, I've updated my original post to prevent problems for future visitors.
Comment #73
woutervu CreditAttribution: woutervu at ezCompany commentedPatch from #45 works with instructions from #67, thanks guys.
Included is a patch adds the truncate table line to taxonomy_update_8501() as suggested in #69. I left out the schema version line, since that seems hacky and doesn't belong in an update hook, in my opinion. Add this patch after the one from #45.
NOTE: This is only necessary if the update failed before, since the taxonomy_term__parent did not exist prior to 8.6.1. A drush sql-drop and a 'clean' 8.5.4 DB backup did the trick for me (with patch #45).
Comment #74
dat deaf drupaler CreditAttribution: dat deaf drupaler as a volunteer commentedCan confirm patch from #73 above works, thanks!
Comment #75
sandboxplin #73 taxonomy_term__parent table is truncated on every batch step,
so for example, if taxonomy_term_hierarchy table had 1050 rows, and each batch step pick 50 rows, taxonomy_term__parent will have 50 rows at the end of execution.
Comment #76
thuan_ng CreditAttribution: thuan_ng commentedTL;DR, in short:
Comment #77
AaronBaumanI'm super confused - did this make it into 8.6.2?
I'm going from 8.5.4 to 8.6.2 and still experiencing this issue.
Am I missing something?
Do I need to go to latest 8.5.x first?
If the issue is marked "fixed", and i don't have a failed update, seems like i should be able to follow the standard update procedure, no?
Comment #78
longwaveNo, 8.6.2 was a security-only release. You will have to wait for 8.6.3 (assuming it is not another security-only release) or use 8.6.x-dev.
Comment #79
AaronBaumanThanks @longwave
To clarify: if i'm hitting this bug when updating from 8.5.4 (or 8.5.6), is it safe to go to 8.5.8?
Then, can i go from 8.5.8 to 8.6.2 without any core patches?
Comment #80
jaarong CreditAttribution: jaarong commentedI'm still having this issue with 8.6.3 even though it is in the change log. I'm guessing that #73 didn't make it in?
Adding the patch in #73 to 8.6.3 does fix the issue for me though.
Comment #81
longwave@aaronbauman I am not quite clear what you are asking here, but you should be able to go to 8.6.3 directly now and solve this issue for good. Please make a database backup first!
@jaarong To be clear when you say "this issue" do you mean the infinite loop or the "Duplicate entry"? The "Duplicate entry" implies that the update hook had already partially run and that you had not deleted the taxonomy_term__parent before reverting to the older database, which should not exist in any 8.5.x database backup.
Comment #82
jaarong CreditAttribution: jaarong commentedSorry, I wasn't aware there were separate issues. In typing my reply, I remembered that I had tried the update on production with 8.6.1. It deleted some of my taxonomy terms or at least removed them from view. I reverted to 8.5.7 and everything appeared to be normal. But let me sum up what I am seeing:
I am running 8.5.8 and all taxonomy terms are present.
While updating to 8.6.3 without #73, I do get the duplicate entry error referenced in this issue and it won't complete the update.
Updating to 8.6.3 (with #73), updb completes successfully, about half of my terms are removed (some in a hierarchy, some not).
I'm not sure what to do at this point, and I'm very glad that security fixes are being offered for 8.5 till May 2019. So let's assume that I somehow ran the update_hook in a previous 8.6 version, is there a way forward for me that doesn't include restoring a database backup that is now 2 months old?
I don't have that many terms and don't have lots of content assigned to the terms deleted, so if I had to do this manually, my preference would be to just recreate the terms and assign them back to the content. That being better than restoring a 2 month old db and losing a lot of content I have entered. But will the db be ok at that point for future updates?
Comment #83
Eric_A CreditAttribution: Eric_A at Dutch Open Projects commentedRemoved or unpublished? Note that there's also #2998221: Primary language taxonomy terms unpublished during 8.6.0 upgrade.
Comment #84
catchThe patch in #45 went out with Drupal 8.6.3.
This does not fix the 'duplicate error' because that is caused by re-running an update on a database that's already been updated.
You can run
'TRUNCATE taxonomy_term__parent;'
from the MySQL cli to empty that table before attempting to re-run the update (this is what the patch in #73 does), or ideally restore a clean backup of your 8.5.x database and run updates on that.Comment #85
jaarong CreditAttribution: jaarong commentedI don't have multiple languages, but one direction that thread did take me in is making a view to show all of my terms. Oddly enough, all of them are still there. They are published according to views. They simply don't show up in the vocabulary list. They are associated with the proper content, but when you edit that content node, the term isn't there.
Saving the term seems to restore the term to the vocabulary page and restore the term on the node edit form. Hierarchy no longer exists for the restored terms, but in my case, that isn't going to take that long to fix.
Saving all terms through Views Bulk Operations also works to get them to reappear. It also looks like maybe the previous 8.6 try unchecked auto-alias on all terms that existed at the time.
All in all, I'm hoping this is all that it takes to restore this to what it was. Maybe someone could let me know if the above all sounds relatively normal and that saving the terms again is something that should fix the problems above?
Edit: Again, this is after updating with 8.6.3 and patch from #73 above.
Comment #86
aolsen356 CreditAttribution: aolsen356 commentedThis patch worked for me after I truncated the taxonomy_term__parent table that was created during the first attempt at upgrading. The upgrade replaces the taxonomy_hierarchy table with taxonomy_term__parent.
Comment #88
ueshiy CreditAttribution: ueshiy at Digital Circus commented#73 can make most of taxonomy hierarchy items lost when processing in multiple batches.
This problem is due to
$database->truncate('taxonomy_term__parent')->execute();
runs on each batch.So use this one instead of #73.