HMS-10723: add endpoint to return template advisory IDs by xbhouse · Pull Request #1536 · content-services/content-sources-backend

xbhouse · 2026-06-10T18:30:36Z

Summary

Adds an endpoint that returns a template's advisory IDs
Sends template update events whenever a template is updated

Testing steps

Create a template with snapshots that have advisories.
Send a GET request to /templates/:uuid/advisories/ids. This should return all the advisory IDs in the template.
Run make kafka-topic-consume KAFKA_TOPIC=platform.content-sources.template
Update the template. There should be 2 messages in the consumer output, one when the update request is sent and one during the update-template-content task.
Add a custom repo to a template that's using the latest snapshots. Triggering a new snapshot for that repo should enqueue the update-latest-snapshot task, and a message should be sent in the consumer output during that task.
Change the template to a date before the latest custom repo snapshot. Delete the custom repo snapshot used by the template, this should enqueue a delete-snapshots task and a message should be sent in the consumer output.
Delete the custom repository used by the template. This should enqueue a delete-repository-snapshots task and a message should be sent during this task too.

xbhouse · 2026-06-10T19:00:08Z

https://issues.redhat.com/browse/HMS-10723

TenSt

lgtm!
There are a couple comments, but feel free to merge as is or I'll re-approve if you decide to do the changes.

rverdile · 2026-06-12T11:10:04Z

 	respTemplate.RepositoryUUIDS = reqTemplate.RepositoryUUIDS

-	event.SendTemplateEvent(*reqTemplate.OrgID, event.TemplateCreated, []event.TemplateEvent{event.MapTemplateResponse(respTemplate, nil, nil)})
-


I'm concerned about removing these events from here because they keep the patch database in sync with our database. If we move them only to the task (which can take some time to start, or fail), I think we might start seeing situations where the databases get out of sync.

What if we left these here, and changed the task to just send TemplateUpdate events for the advisories?

What do you guys think? @xbhouse @TenSt

hmm good point :) keeping the create here makes sense so template data gets sent asap instead of waiting on the task. and i can change the event name for events emitted from the task for new templates to TemplateUpdated

i removed the update event from the dao too, would it make sense to restore that as well for consistency?

yeah, let's restore both

I'm okay with both approaches. We're usually going for the "eventual consistency", so some delay is okay. Depends on the delay. But if we can keep updating right away without loosing any performance or spending too much resources then let's do it.

rverdile · 2026-06-12T13:06:02Z

-	PoolID          *string // Add during task runtime
+	TemplateUUID          string
+	RepoConfigUUIDs       []string
+	PreviousSnapshotUUIDs []string


Should previousSnapshotUUIDs be found at runtime within the task? If the tasks fail or run in a different order than expected, I think this might cause some incorrect errata diffs. Thoughts?

i see what you mean. if 2 update tasks are running for the same template, and one finishes first or fails halfway through, the other would have the wrong prev snapshot uuids.

in cases of out of order tasks or retries, wouldn't checking the prev snapshots inside the task also result in wrong errata diffs? i'll try to test these scenarios with prev snapshots in the payload vs the task to understand more clearly

Hmm so the task takes the repositories that should be in the template in the payload, and when the task is complete the template is in that state. So I think the diff would be okay? But maybe there's still a race condition in there somewhere

Not sure what other options would be except to do this in the handler, and not use a task (maybe too slow?). Or send the whole list to patch and let patch calculate the changes against the system (maybe too many events?).

Can we run the tasks sequentially for the same template? This will create some delay, but will solve these issues. As we're having here async tasks, some delay is inevitable and we can use it to make sure consistency of the data.

the previous snapshots are sent in the payload because these are updated in the db via insertTemplateRepoConfigsAndSnapshots and lost before the task starts. but you're right that this could produce wrong diffs when tasks finish out of order :/ i don't see a way to retrieve or recompute this previous state in the task without storing it somewhere else first, i might have overlooked something though.

doing this in the handler would be slower and maybe too optimistic, meaning we send a diff to patch even if a step afterward fails. sending everything to patch would mean more events, and maybe too many, but it might make sense to have the diff logic where the template-advisory relationships are stored.

if storing the previous snapshots for a template somewhere makes sense or if there's another way to fetch the previous snapshot in the task, i can switch to that. or if we can ensure tasks are run sequentially (maybe this can be done with task dependencies?), that's another option :) otherwise, sending the full set to patch seems like a reasonable approach, but that would be a big design shift so we should talk through it with the team.

discussed a different approach in slack, we're going to add an endpoint patch can use to fetch the current advisories in a template. in patch, whenever there's an event that a template has been updated, we'll query this endpoint and calculate the diff. moving this back to draft while i update this :)

thank you both for your input @rverdile @TenSt!

TenSt

lgtm! great work 👍

rverdile

delete-snapshots and delete-repository-snapshots also modify templates, so those need to send an update event too

xbhouse · 2026-06-16T13:50:55Z

delete-snapshots and delete-repository-snapshots also modify templates, so those need to send an update event too

thank you! was about to ask which other 2 tasks needed to send an event :) will add that in

xbhouse force-pushed the 10723 branch 2 times, most recently from c20e13b to 2129e33 Compare June 10, 2026 18:41

xbhouse force-pushed the 10723 branch 6 times, most recently from 53e9dce to ef2b48a Compare June 11, 2026 21:19

xbhouse marked this pull request as ready for review June 11, 2026 21:46

xbhouse requested a review from a team as a code owner June 11, 2026 21:46

TenSt reviewed Jun 12, 2026

View reviewed changes

Comment thread pkg/dao/rpms.go

TenSt self-assigned this Jun 12, 2026

TenSt reviewed Jun 12, 2026

View reviewed changes

Comment thread pkg/tasks/template_event_helper.go Outdated

TenSt previously approved these changes Jun 12, 2026

View reviewed changes

rverdile reviewed Jun 12, 2026

View reviewed changes

xbhouse dismissed TenSt’s stale review via 6a0e43f June 12, 2026 13:53

xbhouse force-pushed the 10723 branch 2 times, most recently from 6a0e43f to b5cc428 Compare June 12, 2026 17:26

xbhouse marked this pull request as draft June 15, 2026 19:38

xbhouse force-pushed the 10723 branch 2 times, most recently from e8d6e23 to 6331274 Compare June 15, 2026 22:01

xbhouse changed the title ~~HMS-10723: add errata to template message~~ HMS-10723: add endpoint to return template advisory IDs Jun 15, 2026

xbhouse marked this pull request as ready for review June 15, 2026 22:44

TenSt previously approved these changes Jun 16, 2026

View reviewed changes

rverdile reviewed Jun 16, 2026

View reviewed changes

xbhouse dismissed TenSt’s stale review via f574500 June 16, 2026 14:01

xbhouse force-pushed the 10723 branch from 6331274 to f574500 Compare June 16, 2026 14:01

HMS-1072: add endpoint to fetch template advisory ids

e3ca4e0

xbhouse force-pushed the 10723 branch from f574500 to e3ca4e0 Compare June 16, 2026 14:08

		respTemplate.RepositoryUUIDS = reqTemplate.RepositoryUUIDS

		event.SendTemplateEvent(*reqTemplate.OrgID, event.TemplateCreated, []event.TemplateEvent{event.MapTemplateResponse(respTemplate, nil, nil)})

Conversation

xbhouse commented Jun 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Testing steps

Uh oh!

xbhouse commented Jun 10, 2026

Uh oh!

Uh oh!

Uh oh!

TenSt left a comment

Choose a reason for hiding this comment

Uh oh!

rverdile Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xbhouse Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

rverdile Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

TenSt Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

rverdile Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xbhouse Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rverdile Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

TenSt Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

xbhouse Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xbhouse Jun 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TenSt left a comment

Choose a reason for hiding this comment

Uh oh!

rverdile left a comment

Choose a reason for hiding this comment

Uh oh!

xbhouse commented Jun 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

xbhouse commented Jun 10, 2026 •

edited

Loading

rverdile Jun 12, 2026 •

edited

Loading

rverdile Jun 12, 2026 •

edited

Loading

xbhouse Jun 12, 2026 •

edited

Loading

xbhouse Jun 12, 2026 •

edited

Loading

xbhouse Jun 15, 2026 •

edited

Loading