Make content_ids migration incremental and restartable by gerrod3 · Pull Request #8021 · pulp/pulpcore

gerrod3 · 2026-08-27T14:44:26Z

Summary

Rewrite the 0152 content_ids data fill to compute each repository version in Postgres from the previous version (plus added, minus removed) instead of an N+1 ORM loop that ships UUID arrays through Python.
Commit per repository (atomic = False) so a DBaaS statement/session timeout does not roll back already-filled repos. Re-running migrate continues from remaining NULLs, then AlterField makes the column required.
Alternative to fix(0152_alter_repositoryversion_content_ids): add a batch size to avoid timeout on large update #8017: shrinking bulk_update batches does not fix the per-version recompute or the single wrapping transaction.

Test plan

Unit test covering add/remove across versions, already-filled post-3.83 versions as the incremental base, and a second repo left untouched
CI unit tests on this PR
Confirm an upgrade that previously died on 0152 can re-run migrate without losing progress

Made with Cursor

mdellweg · 2026-08-27T14:55:23Z


 class Migration(migrations.Migration):
+ # Per-repository commits inside RunPython; AlterField runs afterwards.
+ atomic = False


This opens up a window, right?
But as long as nothing runs at the same time, or (in the case of ZDU) the currently running code is sufficiantly new there is nothing to introduce new repository versions with NULL. I think this is actually fine.

Maybe, if the user is doing a big jump and trying to do ZDU they might run into a problem if an old worker gets a task to create a new repo-vesion. Theoretically if that were to happen and then the ALTER TABLE call fails, they could just rerun the migration again and we would only need to update that one new repo-version that slipped through.

"big jump and ZDU" is not supported. Let's please not use vague language around that.

Gotcha, then there should be no window if they upgrade properly.

mdellweg · 2026-08-27T15:03:22Z


 import django.contrib.postgres.fields
-from django.db import migrations, models
+from django.db import migrations, models, transaction


I was thinking about something along the lines of
UPDATE core.repositoryversion AS rv SET content_ids=(SELECT ARRAY_AGG(content_id) FROM core.repositoryversion_content WHERE version_added <= rv.version and version_removed > rv.version) WHERE rv.content_ids is NULL;
Maybe needs a few more joins and some care for version_removed = NULL.
Am oversimplifying the challenge here?
Maybe one can even batch that by adding a LIMIT 1000 clause.

Updated the query to be the exact SQL version of _content_relationships. Calculating the memberships can take a little while so not sure if batching them would be good if we want to avoid timeouts.

Perform the cache populating entirely in SQL and add per repository commits. Assisted By: Cursor Grok 4.6 Co-authored-by: Cursor <cursoragent@cursor.com>

patchback · 2026-08-31T17:17:50Z

Backport to 3.116: 💚 backport PR created

✅ Backport PR branch: patchback/backports/3.116/edef435849726ca02cda937da16bdd7a0abc1ea4/pr-8021

Backported as #8031

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.

gerrod3 · 2026-08-27T14:44:26Z

Summary

Rewrite the 0152 content_ids data fill to compute each repository version in Postgres from the previous version (plus added, minus removed) instead of an N+1 ORM loop that ships UUID arrays through Python.
Commit per repository (atomic = False) so a DBaaS statement/session timeout does not roll back already-filled repos. Re-running migrate continues from remaining NULLs, then AlterField makes the column required.
Alternative to fix(0152_alter_repositoryversion_content_ids): add a batch size to avoid timeout on large update #8017: shrinking bulk_update batches does not fix the per-version recompute or the single wrapping transaction.

Test plan

Unit test covering add/remove across versions, already-filled post-3.83 versions as the incremental base, and a second repo left untouched
CI unit tests on this PR
Confirm an upgrade that previously died on 0152 can re-run migrate without losing progress

Made with Cursor

mdellweg · 2026-08-27T14:55:23Z


 class Migration(migrations.Migration):
+ # Per-repository commits inside RunPython; AlterField runs afterwards.
+ atomic = False


This opens up a window, right?
But as long as nothing runs at the same time, or (in the case of ZDU) the currently running code is sufficiantly new there is nothing to introduce new repository versions with NULL. I think this is actually fine.

Maybe, if the user is doing a big jump and trying to do ZDU they might run into a problem if an old worker gets a task to create a new repo-vesion. Theoretically if that were to happen and then the ALTER TABLE call fails, they could just rerun the migration again and we would only need to update that one new repo-version that slipped through.

"big jump and ZDU" is not supported. Let's please not use vague language around that.

Gotcha, then there should be no window if they upgrade properly.

mdellweg · 2026-08-27T15:03:22Z


 import django.contrib.postgres.fields
-from django.db import migrations, models
+from django.db import migrations, models, transaction


I was thinking about something along the lines of
UPDATE core.repositoryversion AS rv SET content_ids=(SELECT ARRAY_AGG(content_id) FROM core.repositoryversion_content WHERE version_added <= rv.version and version_removed > rv.version) WHERE rv.content_ids is NULL;
Maybe needs a few more joins and some care for version_removed = NULL.
Am oversimplifying the challenge here?
Maybe one can even batch that by adding a LIMIT 1000 clause.

Updated the query to be the exact SQL version of _content_relationships. Calculating the memberships can take a little while so not sure if batching them would be good if we want to avoid timeouts.

Perform the cache populating entirely in SQL and add per repository commits. Assisted By: Cursor Grok 4.6 Co-authored-by: Cursor <cursoragent@cursor.com>

patchback · 2026-08-31T17:17:50Z

Backport to 3.116: 💚 backport PR created

✅ Backport PR branch: patchback/backports/3.116/edef435849726ca02cda937da16bdd7a0abc1ea4/pr-8021

Backported as #8031

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.

gerrod3 · 2026-08-27T14:44:26Z

Summary

Rewrite the 0152 content_ids data fill to compute each repository version in Postgres from the previous version (plus added, minus removed) instead of an N+1 ORM loop that ships UUID arrays through Python.
Commit per repository (atomic = False) so a DBaaS statement/session timeout does not roll back already-filled repos. Re-running migrate continues from remaining NULLs, then AlterField makes the column required.
Alternative to fix(0152_alter_repositoryversion_content_ids): add a batch size to avoid timeout on large update #8017: shrinking bulk_update batches does not fix the per-version recompute or the single wrapping transaction.

Test plan

Unit test covering add/remove across versions, already-filled post-3.83 versions as the incremental base, and a second repo left untouched
CI unit tests on this PR
Confirm an upgrade that previously died on 0152 can re-run migrate without losing progress

Made with Cursor

mdellweg · 2026-08-27T14:55:23Z


 class Migration(migrations.Migration):
+ # Per-repository commits inside RunPython; AlterField runs afterwards.
+ atomic = False


This opens up a window, right?
But as long as nothing runs at the same time, or (in the case of ZDU) the currently running code is sufficiantly new there is nothing to introduce new repository versions with NULL. I think this is actually fine.

Maybe, if the user is doing a big jump and trying to do ZDU they might run into a problem if an old worker gets a task to create a new repo-vesion. Theoretically if that were to happen and then the ALTER TABLE call fails, they could just rerun the migration again and we would only need to update that one new repo-version that slipped through.

"big jump and ZDU" is not supported. Let's please not use vague language around that.

Gotcha, then there should be no window if they upgrade properly.

mdellweg · 2026-08-27T15:03:22Z


 import django.contrib.postgres.fields
-from django.db import migrations, models
+from django.db import migrations, models, transaction


I was thinking about something along the lines of
UPDATE core.repositoryversion AS rv SET content_ids=(SELECT ARRAY_AGG(content_id) FROM core.repositoryversion_content WHERE version_added <= rv.version and version_removed > rv.version) WHERE rv.content_ids is NULL;
Maybe needs a few more joins and some care for version_removed = NULL.
Am oversimplifying the challenge here?
Maybe one can even batch that by adding a LIMIT 1000 clause.

Updated the query to be the exact SQL version of _content_relationships. Calculating the memberships can take a little while so not sure if batching them would be good if we want to avoid timeouts.

Perform the cache populating entirely in SQL and add per repository commits. Assisted By: Cursor Grok 4.6 Co-authored-by: Cursor <cursoragent@cursor.com>

patchback · 2026-08-31T17:17:50Z

Backport to 3.116: 💚 backport PR created

✅ Backport PR branch: patchback/backports/3.116/edef435849726ca02cda937da16bdd7a0abc1ea4/pr-8021

Backported as #8031

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.

gerrod3 · 2026-08-27T14:44:26Z

Summary

Rewrite the 0152 content_ids data fill to compute each repository version in Postgres from the previous version (plus added, minus removed) instead of an N+1 ORM loop that ships UUID arrays through Python.
Commit per repository (atomic = False) so a DBaaS statement/session timeout does not roll back already-filled repos. Re-running migrate continues from remaining NULLs, then AlterField makes the column required.
Alternative to fix(0152_alter_repositoryversion_content_ids): add a batch size to avoid timeout on large update #8017: shrinking bulk_update batches does not fix the per-version recompute or the single wrapping transaction.

Test plan

Unit test covering add/remove across versions, already-filled post-3.83 versions as the incremental base, and a second repo left untouched
CI unit tests on this PR
Confirm an upgrade that previously died on 0152 can re-run migrate without losing progress

Made with Cursor

mdellweg · 2026-08-27T14:55:23Z


 class Migration(migrations.Migration):
+ # Per-repository commits inside RunPython; AlterField runs afterwards.
+ atomic = False


This opens up a window, right?
But as long as nothing runs at the same time, or (in the case of ZDU) the currently running code is sufficiantly new there is nothing to introduce new repository versions with NULL. I think this is actually fine.

Maybe, if the user is doing a big jump and trying to do ZDU they might run into a problem if an old worker gets a task to create a new repo-vesion. Theoretically if that were to happen and then the ALTER TABLE call fails, they could just rerun the migration again and we would only need to update that one new repo-version that slipped through.

"big jump and ZDU" is not supported. Let's please not use vague language around that.

Gotcha, then there should be no window if they upgrade properly.

mdellweg · 2026-08-27T15:03:22Z


 import django.contrib.postgres.fields
-from django.db import migrations, models
+from django.db import migrations, models, transaction


I was thinking about something along the lines of
UPDATE core.repositoryversion AS rv SET content_ids=(SELECT ARRAY_AGG(content_id) FROM core.repositoryversion_content WHERE version_added <= rv.version and version_removed > rv.version) WHERE rv.content_ids is NULL;
Maybe needs a few more joins and some care for version_removed = NULL.
Am oversimplifying the challenge here?
Maybe one can even batch that by adding a LIMIT 1000 clause.

Updated the query to be the exact SQL version of _content_relationships. Calculating the memberships can take a little while so not sure if batching them would be good if we want to avoid timeouts.

Perform the cache populating entirely in SQL and add per repository commits. Assisted By: Cursor Grok 4.6 Co-authored-by: Cursor <cursoragent@cursor.com>

patchback · 2026-08-31T17:17:50Z

Backport to 3.116: 💚 backport PR created

✅ Backport PR branch: patchback/backports/3.116/edef435849726ca02cda937da16bdd7a0abc1ea4/pr-8021

Backported as #8031

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.

gerrod3 · 2026-08-27T14:44:26Z

Summary

Rewrite the 0152 content_ids data fill to compute each repository version in Postgres from the previous version (plus added, minus removed) instead of an N+1 ORM loop that ships UUID arrays through Python.
Commit per repository (atomic = False) so a DBaaS statement/session timeout does not roll back already-filled repos. Re-running migrate continues from remaining NULLs, then AlterField makes the column required.
Alternative to fix(0152_alter_repositoryversion_content_ids): add a batch size to avoid timeout on large update #8017: shrinking bulk_update batches does not fix the per-version recompute or the single wrapping transaction.

Test plan

Unit test covering add/remove across versions, already-filled post-3.83 versions as the incremental base, and a second repo left untouched
CI unit tests on this PR
Confirm an upgrade that previously died on 0152 can re-run migrate without losing progress

Made with Cursor

mdellweg · 2026-08-27T14:55:23Z


 class Migration(migrations.Migration):
+ # Per-repository commits inside RunPython; AlterField runs afterwards.
+ atomic = False


This opens up a window, right?
But as long as nothing runs at the same time, or (in the case of ZDU) the currently running code is sufficiantly new there is nothing to introduce new repository versions with NULL. I think this is actually fine.

Maybe, if the user is doing a big jump and trying to do ZDU they might run into a problem if an old worker gets a task to create a new repo-vesion. Theoretically if that were to happen and then the ALTER TABLE call fails, they could just rerun the migration again and we would only need to update that one new repo-version that slipped through.

"big jump and ZDU" is not supported. Let's please not use vague language around that.

Gotcha, then there should be no window if they upgrade properly.

mdellweg · 2026-08-27T15:03:22Z


 import django.contrib.postgres.fields
-from django.db import migrations, models
+from django.db import migrations, models, transaction


I was thinking about something along the lines of
UPDATE core.repositoryversion AS rv SET content_ids=(SELECT ARRAY_AGG(content_id) FROM core.repositoryversion_content WHERE version_added <= rv.version and version_removed > rv.version) WHERE rv.content_ids is NULL;
Maybe needs a few more joins and some care for version_removed = NULL.
Am oversimplifying the challenge here?
Maybe one can even batch that by adding a LIMIT 1000 clause.

Updated the query to be the exact SQL version of _content_relationships. Calculating the memberships can take a little while so not sure if batching them would be good if we want to avoid timeouts.

Perform the cache populating entirely in SQL and add per repository commits. Assisted By: Cursor Grok 4.6 Co-authored-by: Cursor <cursoragent@cursor.com>

patchback · 2026-08-31T17:17:50Z

Backport to 3.116: 💚 backport PR created

✅ Backport PR branch: patchback/backports/3.116/edef435849726ca02cda937da16bdd7a0abc1ea4/pr-8021

Backported as #8031

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.

gerrod3 · 2026-08-27T14:44:26Z

Summary

Rewrite the 0152 content_ids data fill to compute each repository version in Postgres from the previous version (plus added, minus removed) instead of an N+1 ORM loop that ships UUID arrays through Python.
Commit per repository (atomic = False) so a DBaaS statement/session timeout does not roll back already-filled repos. Re-running migrate continues from remaining NULLs, then AlterField makes the column required.
Alternative to fix(0152_alter_repositoryversion_content_ids): add a batch size to avoid timeout on large update #8017: shrinking bulk_update batches does not fix the per-version recompute or the single wrapping transaction.

Test plan

Unit test covering add/remove across versions, already-filled post-3.83 versions as the incremental base, and a second repo left untouched
CI unit tests on this PR
Confirm an upgrade that previously died on 0152 can re-run migrate without losing progress

Made with Cursor

mdellweg · 2026-08-27T14:55:23Z


 class Migration(migrations.Migration):
+ # Per-repository commits inside RunPython; AlterField runs afterwards.
+ atomic = False


This opens up a window, right?
But as long as nothing runs at the same time, or (in the case of ZDU) the currently running code is sufficiantly new there is nothing to introduce new repository versions with NULL. I think this is actually fine.

Maybe, if the user is doing a big jump and trying to do ZDU they might run into a problem if an old worker gets a task to create a new repo-vesion. Theoretically if that were to happen and then the ALTER TABLE call fails, they could just rerun the migration again and we would only need to update that one new repo-version that slipped through.

"big jump and ZDU" is not supported. Let's please not use vague language around that.

Gotcha, then there should be no window if they upgrade properly.

mdellweg · 2026-08-27T15:03:22Z


 import django.contrib.postgres.fields
-from django.db import migrations, models
+from django.db import migrations, models, transaction


I was thinking about something along the lines of
UPDATE core.repositoryversion AS rv SET content_ids=(SELECT ARRAY_AGG(content_id) FROM core.repositoryversion_content WHERE version_added <= rv.version and version_removed > rv.version) WHERE rv.content_ids is NULL;
Maybe needs a few more joins and some care for version_removed = NULL.
Am oversimplifying the challenge here?
Maybe one can even batch that by adding a LIMIT 1000 clause.

Updated the query to be the exact SQL version of _content_relationships. Calculating the memberships can take a little while so not sure if batching them would be good if we want to avoid timeouts.

Perform the cache populating entirely in SQL and add per repository commits. Assisted By: Cursor Grok 4.6 Co-authored-by: Cursor <cursoragent@cursor.com>

patchback · 2026-08-31T17:17:50Z

Backport to 3.116: 💚 backport PR created

✅ Backport PR branch: patchback/backports/3.116/edef435849726ca02cda937da16bdd7a0abc1ea4/pr-8021

Backported as #8031

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.

gerrod3 · 2026-08-27T14:44:26Z

Summary

Rewrite the 0152 content_ids data fill to compute each repository version in Postgres from the previous version (plus added, minus removed) instead of an N+1 ORM loop that ships UUID arrays through Python.
Commit per repository (atomic = False) so a DBaaS statement/session timeout does not roll back already-filled repos. Re-running migrate continues from remaining NULLs, then AlterField makes the column required.
Alternative to fix(0152_alter_repositoryversion_content_ids): add a batch size to avoid timeout on large update #8017: shrinking bulk_update batches does not fix the per-version recompute or the single wrapping transaction.

Test plan

Unit test covering add/remove across versions, already-filled post-3.83 versions as the incremental base, and a second repo left untouched
CI unit tests on this PR
Confirm an upgrade that previously died on 0152 can re-run migrate without losing progress

Made with Cursor

mdellweg · 2026-08-27T14:55:23Z


 class Migration(migrations.Migration):
+ # Per-repository commits inside RunPython; AlterField runs afterwards.
+ atomic = False


This opens up a window, right?
But as long as nothing runs at the same time, or (in the case of ZDU) the currently running code is sufficiantly new there is nothing to introduce new repository versions with NULL. I think this is actually fine.

Maybe, if the user is doing a big jump and trying to do ZDU they might run into a problem if an old worker gets a task to create a new repo-vesion. Theoretically if that were to happen and then the ALTER TABLE call fails, they could just rerun the migration again and we would only need to update that one new repo-version that slipped through.

"big jump and ZDU" is not supported. Let's please not use vague language around that.

Gotcha, then there should be no window if they upgrade properly.

mdellweg · 2026-08-27T15:03:22Z


 import django.contrib.postgres.fields
-from django.db import migrations, models
+from django.db import migrations, models, transaction


I was thinking about something along the lines of
UPDATE core.repositoryversion AS rv SET content_ids=(SELECT ARRAY_AGG(content_id) FROM core.repositoryversion_content WHERE version_added <= rv.version and version_removed > rv.version) WHERE rv.content_ids is NULL;
Maybe needs a few more joins and some care for version_removed = NULL.
Am oversimplifying the challenge here?
Maybe one can even batch that by adding a LIMIT 1000 clause.

Updated the query to be the exact SQL version of _content_relationships. Calculating the memberships can take a little while so not sure if batching them would be good if we want to avoid timeouts.

Perform the cache populating entirely in SQL and add per repository commits. Assisted By: Cursor Grok 4.6 Co-authored-by: Cursor <cursoragent@cursor.com>

patchback · 2026-08-31T17:17:50Z

Backport to 3.116: 💚 backport PR created

✅ Backport PR branch: patchback/backports/3.116/edef435849726ca02cda937da16bdd7a0abc1ea4/pr-8021

Backported as #8031

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.

gerrod3 · 2026-08-27T14:44:26Z

Summary

Rewrite the 0152 content_ids data fill to compute each repository version in Postgres from the previous version (plus added, minus removed) instead of an N+1 ORM loop that ships UUID arrays through Python.
Commit per repository (atomic = False) so a DBaaS statement/session timeout does not roll back already-filled repos. Re-running migrate continues from remaining NULLs, then AlterField makes the column required.
Alternative to fix(0152_alter_repositoryversion_content_ids): add a batch size to avoid timeout on large update #8017: shrinking bulk_update batches does not fix the per-version recompute or the single wrapping transaction.

Test plan

Unit test covering add/remove across versions, already-filled post-3.83 versions as the incremental base, and a second repo left untouched
CI unit tests on this PR
Confirm an upgrade that previously died on 0152 can re-run migrate without losing progress

Made with Cursor

mdellweg · 2026-08-27T14:55:23Z


 class Migration(migrations.Migration):
+ # Per-repository commits inside RunPython; AlterField runs afterwards.
+ atomic = False


This opens up a window, right?
But as long as nothing runs at the same time, or (in the case of ZDU) the currently running code is sufficiantly new there is nothing to introduce new repository versions with NULL. I think this is actually fine.

Maybe, if the user is doing a big jump and trying to do ZDU they might run into a problem if an old worker gets a task to create a new repo-vesion. Theoretically if that were to happen and then the ALTER TABLE call fails, they could just rerun the migration again and we would only need to update that one new repo-version that slipped through.

"big jump and ZDU" is not supported. Let's please not use vague language around that.

Gotcha, then there should be no window if they upgrade properly.

mdellweg · 2026-08-27T15:03:22Z


 import django.contrib.postgres.fields
-from django.db import migrations, models
+from django.db import migrations, models, transaction


I was thinking about something along the lines of
UPDATE core.repositoryversion AS rv SET content_ids=(SELECT ARRAY_AGG(content_id) FROM core.repositoryversion_content WHERE version_added <= rv.version and version_removed > rv.version) WHERE rv.content_ids is NULL;
Maybe needs a few more joins and some care for version_removed = NULL.
Am oversimplifying the challenge here?
Maybe one can even batch that by adding a LIMIT 1000 clause.

Updated the query to be the exact SQL version of _content_relationships. Calculating the memberships can take a little while so not sure if batching them would be good if we want to avoid timeouts.

Perform the cache populating entirely in SQL and add per repository commits. Assisted By: Cursor Grok 4.6 Co-authored-by: Cursor <cursoragent@cursor.com>

patchback · 2026-08-31T17:17:50Z

Backport to 3.116: 💚 backport PR created

✅ Backport PR branch: patchback/backports/3.116/edef435849726ca02cda937da16bdd7a0abc1ea4/pr-8021

Backported as #8031

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.

github-actionsBot added the no-issue label Aug 27, 2026

gerrod3 marked this pull request as draft August 27, 2026 14:46

mdellweg reviewed Aug 27, 2026
View reviewed changes

Make content_ids migration incremental and restartable
ceba57e
Perform the cache populating entirely in SQL and add per repository commits. Assisted By: Cursor Grok 4.6 Co-authored-by: Cursor <cursoragent@cursor.com>

gerrod3 force-pushed the fix/0152-content-ids-migration branch from 87e316f to ceba57eCompare August 31, 2026 15:54

mdellweg approved these changes Aug 31, 2026
View reviewed changes

gerrod3 marked this pull request as ready for review August 31, 2026 17:14

gerrod3 added the backport-3.116 label Aug 31, 2026

gerrod3 merged commit edef435 into pulp:mainAug 31, 2026
13 of 14 checks passed

gerrod3 deleted the fix/0152-content-ids-migration branch August 31, 2026 17:17

patchbackBot mentioned this pull request Aug 31, 2026
[PR #8021/edef4358 backport][3.116] Make content_ids migration incremental and restartable #8031
Merged
3 tasks

github-actionsBot added the no-issue label Aug 27, 2026

gerrod3 marked this pull request as draft August 27, 2026 14:46

mdellweg reviewed Aug 27, 2026
View reviewed changes

Make content_ids migration incremental and restartable
ceba57e
Perform the cache populating entirely in SQL and add per repository commits. Assisted By: Cursor Grok 4.6 Co-authored-by: Cursor <cursoragent@cursor.com>

gerrod3 force-pushed the fix/0152-content-ids-migration branch from 87e316f to ceba57eCompare August 31, 2026 15:54

mdellweg approved these changes Aug 31, 2026
View reviewed changes

gerrod3 marked this pull request as ready for review August 31, 2026 17:14

gerrod3 added the backport-3.116 label Aug 31, 2026

gerrod3 merged commit edef435 into pulp:mainAug 31, 2026
13 of 14 checks passed

gerrod3 deleted the fix/0152-content-ids-migration branch August 31, 2026 17:17

patchbackBot mentioned this pull request Aug 31, 2026
[PR #8021/edef4358 backport][3.116] Make content_ids migration incremental and restartable #8031
Merged
3 tasks

github-actionsBot added the no-issue label Aug 27, 2026

gerrod3 marked this pull request as draft August 27, 2026 14:46

mdellweg reviewed Aug 27, 2026
View reviewed changes

Make content_ids migration incremental and restartable
ceba57e
Perform the cache populating entirely in SQL and add per repository commits. Assisted By: Cursor Grok 4.6 Co-authored-by: Cursor <cursoragent@cursor.com>

gerrod3 force-pushed the fix/0152-content-ids-migration branch from 87e316f to ceba57eCompare August 31, 2026 15:54

mdellweg approved these changes Aug 31, 2026
View reviewed changes

gerrod3 marked this pull request as ready for review August 31, 2026 17:14

gerrod3 added the backport-3.116 label Aug 31, 2026

gerrod3 merged commit edef435 into pulp:mainAug 31, 2026
13 of 14 checks passed

gerrod3 deleted the fix/0152-content-ids-migration branch August 31, 2026 17:17

patchbackBot mentioned this pull request Aug 31, 2026
[PR #8021/edef4358 backport][3.116] Make content_ids migration incremental and restartable #8031
Merged
3 tasks

github-actionsBot added the no-issue label Aug 27, 2026

gerrod3 marked this pull request as draft August 27, 2026 14:46

mdellweg reviewed Aug 27, 2026
View reviewed changes

Make content_ids migration incremental and restartable
ceba57e
Perform the cache populating entirely in SQL and add per repository commits. Assisted By: Cursor Grok 4.6 Co-authored-by: Cursor <cursoragent@cursor.com>

gerrod3 force-pushed the fix/0152-content-ids-migration branch from 87e316f to ceba57eCompare August 31, 2026 15:54

mdellweg approved these changes Aug 31, 2026
View reviewed changes

gerrod3 marked this pull request as ready for review August 31, 2026 17:14

gerrod3 added the backport-3.116 label Aug 31, 2026

gerrod3 merged commit edef435 into pulp:mainAug 31, 2026
13 of 14 checks passed

gerrod3 deleted the fix/0152-content-ids-migration branch August 31, 2026 17:17

patchbackBot mentioned this pull request Aug 31, 2026
[PR #8021/edef4358 backport][3.116] Make content_ids migration incremental and restartable #8031
Merged
3 tasks

github-actionsBot added the no-issue label Aug 27, 2026

gerrod3 marked this pull request as draft August 27, 2026 14:46

mdellweg reviewed Aug 27, 2026
View reviewed changes

Make content_ids migration incremental and restartable
ceba57e
Perform the cache populating entirely in SQL and add per repository commits. Assisted By: Cursor Grok 4.6 Co-authored-by: Cursor <cursoragent@cursor.com>

gerrod3 force-pushed the fix/0152-content-ids-migration branch from 87e316f to ceba57eCompare August 31, 2026 15:54

mdellweg approved these changes Aug 31, 2026
View reviewed changes

gerrod3 marked this pull request as ready for review August 31, 2026 17:14

gerrod3 added the backport-3.116 label Aug 31, 2026

gerrod3 merged commit edef435 into pulp:mainAug 31, 2026
13 of 14 checks passed

gerrod3 deleted the fix/0152-content-ids-migration branch August 31, 2026 17:17

patchbackBot mentioned this pull request Aug 31, 2026
[PR #8021/edef4358 backport][3.116] Make content_ids migration incremental and restartable #8031
Merged
3 tasks

github-actionsBot added the no-issue label Aug 27, 2026

gerrod3 marked this pull request as draft August 27, 2026 14:46

mdellweg reviewed Aug 27, 2026
View reviewed changes

Make content_ids migration incremental and restartable
ceba57e
Perform the cache populating entirely in SQL and add per repository commits. Assisted By: Cursor Grok 4.6 Co-authored-by: Cursor <cursoragent@cursor.com>

gerrod3 force-pushed the fix/0152-content-ids-migration branch from 87e316f to ceba57eCompare August 31, 2026 15:54

mdellweg approved these changes Aug 31, 2026
View reviewed changes

gerrod3 marked this pull request as ready for review August 31, 2026 17:14

gerrod3 added the backport-3.116 label Aug 31, 2026

gerrod3 merged commit edef435 into pulp:mainAug 31, 2026
13 of 14 checks passed

gerrod3 deleted the fix/0152-content-ids-migration branch August 31, 2026 17:17

patchbackBot mentioned this pull request Aug 31, 2026
[PR #8021/edef4358 backport][3.116] Make content_ids migration incremental and restartable #8031
Merged
3 tasks

github-actionsBot added the no-issue label Aug 27, 2026

gerrod3 marked this pull request as draft August 27, 2026 14:46

mdellweg reviewed Aug 27, 2026
View reviewed changes

Make content_ids migration incremental and restartable
ceba57e
Perform the cache populating entirely in SQL and add per repository commits. Assisted By: Cursor Grok 4.6 Co-authored-by: Cursor <cursoragent@cursor.com>

gerrod3 force-pushed the fix/0152-content-ids-migration branch from 87e316f to ceba57eCompare August 31, 2026 15:54

mdellweg approved these changes Aug 31, 2026
View reviewed changes

gerrod3 marked this pull request as ready for review August 31, 2026 17:14

gerrod3 added the backport-3.116 label Aug 31, 2026

gerrod3 merged commit edef435 into pulp:mainAug 31, 2026
13 of 14 checks passed

gerrod3 deleted the fix/0152-content-ids-migration branch August 31, 2026 17:17

patchbackBot mentioned this pull request Aug 31, 2026
[PR #8021/edef4358 backport][3.116] Make content_ids migration incremental and restartable #8031
Merged
3 tasks

github-actionsBot added the no-issue label Aug 27, 2026

gerrod3 marked this pull request as draft August 27, 2026 14:46

mdellweg reviewed Aug 27, 2026
View reviewed changes

Make content_ids migration incremental and restartable
ceba57e
Perform the cache populating entirely in SQL and add per repository commits. Assisted By: Cursor Grok 4.6 Co-authored-by: Cursor <cursoragent@cursor.com>

gerrod3 force-pushed the fix/0152-content-ids-migration branch from 87e316f to ceba57eCompare August 31, 2026 15:54

mdellweg approved these changes Aug 31, 2026
View reviewed changes

gerrod3 marked this pull request as ready for review August 31, 2026 17:14

gerrod3 added the backport-3.116 label Aug 31, 2026

gerrod3 merged commit edef435 into pulp:mainAug 31, 2026
13 of 14 checks passed

gerrod3 deleted the fix/0152-content-ids-migration branch August 31, 2026 17:17

patchbackBot mentioned this pull request Aug 31, 2026
[PR #8021/edef4358 backport][3.116] Make content_ids migration incremental and restartable #8031
Merged
3 tasks

Uh oh!

Conversation

gerrod3 commented Aug 27, 2026

Summary

Test plan

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

patchbackBot commented Aug 31, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Backport to 3.116: 💚 backport PR created

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

gerrod3 commented Aug 27, 2026

Summary

Test plan

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

patchbackBot commented Aug 31, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Backport to 3.116: 💚 backport PR created

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

gerrod3 commented Aug 27, 2026

Summary

Test plan

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

patchbackBot commented Aug 31, 2026•
edited
Loading

patchbackBot commented Aug 31, 2026•
edited
Loading

patchbackBot commented Aug 31, 2026•
edited
Loading