D7 upgrade migration test shows incorrect node created, updated values are migrated

If I understand this correctly I actually think this is an error in the database. The database fixture has not always been created via the UI and sometimes this are not quite right.

However, I think the logic is correct here. That node has been translated so getting the dates from the entity translation table seems to be correct. To verify this, I tested on Drupal 7 starting with the current test fixture. I then added a new node of the same content type (one that uses entity translation) and added a French translation. I then looked at the dates in the node/node_revision and entity/entity_revision tables. Sorry, I didn't output that data. I concluded that the values for created/changed in the entity/entity_revision tables should be the same as the English node in the node/node_revision tables.

I have made a patch that changes those dates and MigrateNodeCompleteTest.

What's a good way to test this?

Then maybe we need test coverage for the data without translations? IMHO that's why the existing test coverage hasn't failed for the revision timestamp value.

I don't see how that will help. The incorrect data was in the entity_translation tables. And the node complete migration is designed to get everything. To run d7_node_complete without translations defeats its purpose.

@smustgrave, the only way I can think of to test this is to use a Drupal 7 site. Add entity_translation and i18n. Enable entity translation for a for a content type and another language. Then add a node of that content type and add a translation. Then examine the timestamps for the node in the node/node_revision and entity_translation/entity_translation_revision tables. You want to make sure that the pattern of changes matches what is in the patch and node tables for drupal7.php.

English
Created - 1690313326
Changed - 1690313326

Spanish
Created - 1690313497
Changed - 1690313497

Ran the fixture DB dump to drupal7.php
Verified the nodes created and changed dates are matching.

The last submitted patch, 6: 3303925-6.patch, failed testing. View results →

There was an unrelated failure.

1) Drupal\Tests\user\Functional\UserCancelTest::testMassUserCancelByAdmin
Behat\Mink\Exception\ElementNotFoundException: Button with id|name|label|value "Apply to selected items" not found.

I retested and tests are passing, so restoring RTBC.

Restoring to RTBC.

The last submitted patch, 6: 3303925-6.patch, failed testing. View results →

Unrelated fail, retesting.

1) Drupal\Tests\system\Functional\System\CronRunTest::testAutomatedCron
Failed asserting that 1690508392 is less than 1690508392.

Tests passing again, back to rtbc

I'm triaging RTBC issues → .

I've read the issue summary, comments and patch. All I see is that the proposed resolution does not match what is implemented. I have updated that now.

The last submitted patch, 6: 3303925-6.patch, failed testing. View results →

Unrelated failure, retesting

1) Drupal\Tests\ckeditor5\FunctionalJavascript\MediaTest::testViewMode with data set "without alignment" (false)
Behat\Mink\Exception\ElementNotFoundException: Element matching css "article.media--view-mode-view-mode-1" not found.

Does seem to be random

The last submitted patch, 6: 3303925-6.patch, failed testing. View results →

Seems to be unrelated.

The Needs Review Queue Bot → tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request → . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

Hiding files and converted #6 to an MR.

Please do not credit me if I did not other wise earn it as all I did was convert this.

Restoring status

I'm going to go back to the point that the problem is the "changed" value is not migrated correctly when translations are not used,

To run d7_node_complete without translations defeats its purpose.

I've used d7_node_complete as a base for several migrations, none of them had translations. When you run "migrate:import --configure-only" it uses d7_node_complete, even if the source site didn't use translations.

Putting this back to "needs work" as I strongly feel the actual problem is not being fixed.

In practice I find that using the "timestamp" source property gives the correct value migrations, not the "changed" value as it results in the wrong value if the migration is updated (via Drush and migrate_tools).

What's weird is that sometimes using changed:timestamp results in incorrect values, but running the migration again corrects it. Go figure.