Closed sadsfae closed 2 weeks ago
Looking at the code you posted which comes from https://github.com/redhat-performance/quads/blob/latest/src/quads/cli/cli.py#L658 the "data" object is being passed to each of the calls to self.quads.update_notification()
a few lines further down on https://github.com/redhat-performance/quads/blob/latest/src/quads/cli/cli.py#L665 which is done inside of the for loop that iterates over the schedules (the for loop starts on https://github.com/redhat-performance/quads/blob/latest/src/quads/cli/cli.py#L635 )
So the way that reads, it seems to make multiple calls for each of the schedules. Shouldn't there be only a single call only if the extend operation is done with the --cloud
flag rather than iterating over all the schedules?
The way the code is written here: https://github.com/redhat-performance/quads/blob/latest/src/quads/cli/cli.py#L657 it should reset all the values to False but I don't see that happening looking at the database.
Let's look at a recently extended LTA assignment:
So notification_id is
14
We can see it won't expire until 2025-01-05:
Now let's look at the database notifications table for assignment_id
14
We should see
one_day
,three_days
,five_days
andseven_days
notification flags being reset when it was extended tof
.We are effectively not resetting anything on extension, this means that tenants will only receive the notification they haven't ever received yet or we have no record of and once that happens they won't receive those either.
The code in the
--extend
method is supposed to do this but I don't see it happening in the database: