I can not reproduce this on some small CV/repo (i.e. Sat6.10 tools for RHEL8):

1) sync the repo
2) have CV with that repo BUT applied filter "exclude puppet-agent RPM" (this will remove 1 RPM and 1 errata)
3) incremental update of the CV to add the package and also add the errata:

hammer> content-view version incremental-update --organization-id 1 --content-view-version-id 16 --package-ids 95140
[.....................................................................................................................................................................................] [100%]
Content View: cv_tools_rhel8 version 2.1
Added Content:
  Packages:
        puppet-agent-6.22.1-1.el8sat.x86_64
hammer> content-view version incremental-update --organization-id 1 --content-view-version-id 16 --errata-ids 1
[.....................................................................................................................................................................................] [100%]
Content View: cv_tools_rhel8 version 2.2
Added Content:
  Errata:
        RHBA-2021:4701
  Packages:
        puppet-agent-6.22.1-1.el8sat.x86_64
hammer>



So maybe something related to bigger repos?

.. and also incremental update of CV with RHEL7 (and another with RHEL8 baseos+appstream) went well for me.

The bug hit isn't much generic as originally expected.

OK, there *is* a deterministic reproducer:

1) Create a custom product and repo
2) Upload a package to it
3) Create a CV, add that repo to it and publish
4) Upload another RPM (ideally same Name but higher Version/Release) to the repo
5) incremental update of the CV version fails:

hammer> content-view version incremental-update --organization-id 1 --content-view-version-id 33 --package-ids 95164
[...................................................................................                                                                                                   ] [46%]
Incremental Update incomplete.
Error: Error message: the server returns an error
HTTP status code: 400
Response headers: {"Date"=>"Wed, 19 Jan 2022 11:19:52 GMT", "Server"=>"gunicorn", "Content-Type"=>"application/json", "Vary"=>"Accept,Cookie", "Allow"=>"POST, OPTIONS", "X-Frame-Options"=>"SAMEORIGIN", "Content-Length"=>"74", "Correlation-ID"=>"2f1977aa-d8c6-443f-aa97-984158ef1b5d", "Access-Control-Expose-Headers"=>"Correlation-ID", "Via"=>"1.1 pmoravec-sat610.satotest.gsslab.brq2.redhat.com", "Connection"=>"close"}
Response body: ["Version 1 does not exist for repository 'sos_repo_incremental-695507'."]
hammer> 


So it seem the problem happens when incrementally updating some content that was *missing* in _root_ repository (katello term) at the time of original CV publish / when the CV version (being incremented from) was created.

Anyway, this is the typical use case of incremental update, the "restrict content via filters" is more artificial => quite severe bug (for incremental update).

Lai,
isn't there some automated test for this? I would expect there is / should be..

Hey Pavel,

We do have some tests around incremental update.  Here are some:

https://github.com/SatelliteQE/robottelo/blob/master/tests/foreman/cli/test_contentview.py#L3732

https://github.com/SatelliteQE/robottelo/blob/master/tests/foreman/ui/test_contentview.py#L2980

https://github.com/SatelliteQE/robottelo/blob/master/tests/foreman/ui/test_contentview.py#L3041

And then there's a few incremental update test in api/test_errata.py.

If you see that there's some missing coverage, I can put those on my backlog.

I was looking into this community issue which I believe is the same one: https://community.theforeman.org/t/unable-to-publish-an-incremental-cv-update/27085/7

I'm not sure the root cause, but I found some potentially helpful info when debugging the Pulp copy task during incremental update:

For the copy API call to Pulp during MultiCopyUnits, it appears that the "dest_repo" field is set incorrectly to the Pulp repository that is attached to one of the content view version's non-archived repositories.  This incorrect assignment comes from the destination repository's RepositoryReference: https://github.com/Katello/katello/blob/master/app/services/katello/pulp3/repository/yum.rb#L97

It should be the dest_repo for the archived repository instead.  Somehow, the RepositoryReference has a different repository from the ::Katello::Repository :

[87] pry(main)> ::Katello::Pulp3::Repository::Yum.new(::Katello::Repository.find(60), SmartProxy.pulp_primary).repository_reference
=> #<Katello::Pulp3::RepositoryReference:0x000055a2ca5cbb98
 id: 32,
 repository_href: "/pulp/api/v3/repositories/rpm/rpm/afa0e2cf-d25c-4ce9-b367-a54f5be2c481/",
 content_view_id: 18,
 root_repository_id: 16>

compared to:

[89] pry(main)> ::Katello::Repository.find(60).version_href
=> "/pulp/api/v3/repositories/rpm/rpm/d49ad868-8b54-4058-8195-da08a4a89529/versions/2/"



I only saw this happen when I tried Pavel's reproducer steps by uploading a new RPM to a repository.  It does not occur if I test instead by filtering out errata and incrementally adding them back in, for example.

Created redmine issue https://projects.theforeman.org/issues/34357 from this bug

Moving to POST as the upstream PR is now merged.

Hotfix RPM is available for Satellite 6.10.2

OBTAINING THE HOTFIX:

The hotfix RPM is too large to be provided as an attachment on Bugzilla. Therefore please contact Red Hat Technical Support to obtain the hotfix.

INSTALLING THE HOTFIX:

1. Take a complete backup or snapshot of Satellite 6.10.2 server

2. Obtain the hotfix RPM from Red Hat Technical Support and copy it to Satellite server

3. # yum install ./tfm-rubygem-katello-4.1.1.42-3.HOTFIXRHBZ2041497.el7sat.noarch.rpm --disableplugin=foreman-protector

4. # satellite-maintain service restart

Steps to retest

1. Create some repo and sync it
2. Delete some packages from the repo
3. Create a CV, add the repo, and publish
4. Re-sync the repo to get the deleted RPMs back
5. Incrementally add one or more RPMs back in 

Expected:
Incrementally update should be successful

Actual:
Incremental update is successful

I tried this with the zoo repo and removed 'bear' and 'frog' packages.  After following the steps and doing inc update on the missing package, it was added successfully without issues.  I tried this with a ccv and that was also successful.

Verified on 7.0 snap 11.  Tested on both rhel7 and rhel8.

Hello, 

My customer is on 6.10.3 and still facing this issue.

(In reply to Ian Ballou from comment #9)
> I was looking into this community issue which I believe is the same one:
> https://community.theforeman.org/t/unable-to-publish-an-incremental-cv-
> update/27085/7
> 
> I'm not sure the root cause, but I found some potentially helpful info when
> debugging the Pulp copy task during incremental update:
> 
> For the copy API call to Pulp during MultiCopyUnits, it appears that the
> "dest_repo" field is set incorrectly to the Pulp repository that is attached
> to one of the content view version's non-archived repositories.  This
> incorrect assignment comes from the destination repository's
> RepositoryReference:
> https://github.com/Katello/katello/blob/master/app/services/katello/pulp3/
> repository/yum.rb#L97
> 
> It should be the dest_repo for the archived repository instead.  Somehow,
> the RepositoryReference has a different repository from the
> ::Katello::Repository :
> 
> [87] pry(main)>
> ::Katello::Pulp3::Repository::Yum.new(::Katello::Repository.find(60),
> SmartProxy.pulp_primary).repository_reference
> => #<Katello::Pulp3::RepositoryReference:0x000055a2ca5cbb98
>  id: 32,
>  repository_href:
> "/pulp/api/v3/repositories/rpm/rpm/afa0e2cf-d25c-4ce9-b367-a54f5be2c481/",
>  content_view_id: 18,
>  root_repository_id: 16>
> 
> compared to:
> 
> [89] pry(main)> ::Katello::Repository.find(60).version_href
> =>
> "/pulp/api/v3/repositories/rpm/rpm/d49ad868-8b54-4058-8195-da08a4a89529/
> versions/2/"
> 
> 
> 
> I only saw this happen when I tried Pavel's reproducer steps by uploading a
> new RPM to a repository.  It does not occur if I test instead by filtering
> out errata and incrementally adding them back in, for example.

Hi

Pavel's steps are in comment #4

I read through the tests Lai mentioned in comment #6

All currently use filtering to create applicability but no installability.

The CLI test is specifically about not having a LCE.

@lai you could modify "test_positive_errata_inc_update_list_package"[1] to upload an RPM in place of applying a filter




the UI tests are slower than API tests, 
so you could ask @akjha if he can change his API test[2] to upload an RPM in place of applying a filter.
Or just copy and modify it.


[1] https://github.com/SatelliteQE/robottelo/blob/f8b6c8ad742bab67e0f75b0fa63fd4d5d5743476/tests/foreman/ui/test_contentview.py#L2947
[2] https://github.com/SatelliteQE/robottelo/blob/f8b6c8ad742bab67e0f75b0fa63fd4d5d5743476/tests/foreman/api/test_errata.py#L620

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: Satellite 6.11 Release), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:5498