This is to fix #102.
rebased onto eacd3980a7cd729a59b8ff792b760ae304a01cc0
Maybe I am being dumb today, but I don't see how the change in greenwave/consumers/resultsdb.py makes any effective difference to the behaviour of the code?
greenwave/consumers/resultsdb.py
What exactly is the bug and how is this change fixing it?
rebased onto 643f2ffaedccc4611cf767c10b63225185e924fc
The bug is the message hold by the varaible msg declared in line 84 got overwritten here if there are more than one policy applicable to the subject. It's a serious mistake I made, :-)
msg
The tests did not discover it because we did not have a testcase in different policies, so I add one to cover this case.
Oh, I see. I missed the fact that was happening inside a big for loop.
:+1: from me
Could we actually assert both of the expected messages here?
Also... do we really send a separate message for each policy? :thinking:
Shouldn't we be sending one message per decision context (per subject), regardless how many policies apply to that decision context?
I guess this comes back to the same problem again, where we don't necessarily know exactly what decision our consumers are looking for.
Sure, I can assert both of the expected messages.
Yeah, this is how messages are sent. Each message is sent per product context, per product version and per subject.
rebased onto 2fdbc500fd4eda80477a79a3cac74f1f44d94038
This comment should say "as we have two decision contexts applicable to this subject" right?
I think if we have two decision contexts and three policies, we should only publish two messages.
See #105.
Yeah.
rebased onto 42ca84f7709cc982a571b8c338557541d938461d
rebased onto 11bcd4a4fea1e12e3a3a79fdd708cd9ddfacc5f8
Ready to get another look.
:+1: makes sense to me
Pull-Request has been merged by mjia
This is to fix #102.