message plugin for hub #4627
No reviewers
Labels
No labels
backlog
bug
Closed As
Dropped
Closed As
Duplicate
Closed As
Fixed
Closed As
Insufficient data
Closed As
Invalid
deprecation
discussion
doc
easyfix
feature
fedora-infra
groomed
NEEDINFO
no_qe
Priority
High
Priority
Low
Priority
Normal
rhel6-eol
scheduler
tech-debt
testing-basic
testing-custom
testing-done
testing-ready
usability
wishful
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
koji/koji!4627
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "mikem/koji:message-plugin"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This plugin enables client-side message bus connections. It works similarly to the existing protonmsg plugin, but stores messages to the database. A dedicated client can use the
message.poll()andmessage.ack()methods to fetch and acknowledge messages from the queue. These calls require the newmessagepermission.Do we want to handle multiple clients/threads consuming the same data? It would need some locking FOR UPDATE SKIP LOCKED, etc. Maybe docs could be extended that client is using esclusive session if we don't want to support this.
Theoretically there could be also the variant of many clients for many messaging backends. So, queue could be extended to have some tags (like client1 acks it was successful in sending to backend1 and add user_id1 to ack field, while client2 can still fetch/send such message). We wouldn't know how many clients are going to consume the messages, but
max_agewould clean it later anyway, so it wouldn't be there forever.@ -0,0 +207,4 @@'arch': 'x86_64'}sigkey = ''message.prep_rpm_sign('postRPMSign', sigkey=sigkey, sighash='fedcba9876543210',build=build, rpm=rpm)Some assert here, that message is not in the queue?
@ -0,0 +509,4 @@message.parse_bool_str(val)# the endMaybe test for double-ack?
As coded, a double ack is a no-op (unless it happens to trigger an auto clean)
There is no meaningful way to test double ack behavior here. The ack state is in the db table, and the behavior is handled in the update query, which we are mocking. The update clauses always include
sent IS FALSE. We could only be able to test the behavior if we had a working db for the test.@tkopecek wrote in #4627 (comment):
This is deliberately written for a single dedicated client to handle the queue. I've tried to use the term "dedicated client" numerous places to emphasize this. I went this way because it is simpler to implement. Otherwise we need to track sent state per client.
That said, I certainly have considered allowing for multiple clients. I don't think it's needed for our purposes, but it could be useful in the future.
Alternate implementation - koji/koji!4652
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.