Conversation
…aming of queue objects
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #663 +/- ##
==========================================
+ Coverage 88.41% 89.32% +0.90%
==========================================
Files 81 81
Lines 3972 4074 +102
==========================================
+ Hits 3512 3639 +127
+ Misses 460 435 -25 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
stefpiatek
left a comment
There was a problem hiding this comment.
Ah nice, thanks Ruaridh, appreciate cracking this out. Some structural changes and then happy to a more fine-grained review
| # Extract the trace context injected into the request headers by the caller, and pass it to | ||
| # the thread pool job so the import continues the same trace | ||
| headers = {key.lower(): value for key, value in request.get("headers", {}).items()} | ||
| headers = {key.lower(): value for key, value in requests.request.get("headers", {}).items()} |
There was a problem hiding this comment.
Oh hello, I don't think requests will be able to get any headers. You'll probably need to look at was was in the original headers or ask @p-j-smith
There was a problem hiding this comment.
Will have a look and ask @p-j-smith tomorrow if I can't figure it out! I've reduced redundancy in the consumers, producers etc. so hopefully the code is cleaner now (the tests pass apart from the system test)
There was a problem hiding this comment.
ah yeah, so previously the requests auto-instrumentation library injected the headers when calling the ImportStudiesFromRaw endpoint. Now though, the pika auto-instrumentation will handle this - it's installed in the imaging-api Docker Image, and is started when we spin up the container, so this happens automatically.
We can't change the orthanc-anon entrypoint to start the auto-instrumentation libraries, so we need to explicitly call PikaInstrumentor().instrument() so that we can then extract the parent context. We already do this in the CLI:
Line 30 in e29f4b1
Line 74 in e29f4b1
and we'll need to do the same for orthanc-anon. Then when you need to get the parent context, there is a opentelemetry.context.get_current function you can call to get the parent_context
Co-authored-by: Stef Piatek <s.piatek@ucl.ac.uk>
| data = { | ||
| "resource_ids": message.resource_ids, | ||
| "series_uids": message.series_uids, | ||
| "study_uids": message.study_uids, | ||
| "project_name": message.project_name, | ||
| "parent_context": parent_context, | ||
| } |
There was a problem hiding this comment.
_import_studies_from_raw doesn't take a data argument, I think you'll need to keep the same arguments as before (and keep the same names, e.g. study_resource_ids rather than `resource_ids)
|
@p-j-smith |
607eedb to
e97ae06
Compare
p-j-smith
left a comment
There was a problem hiding this comment.
looking good. There's also the question of whether we want to make the new queue async, but for a future PR?
| # Must match the max_priority PixlConsumer declares this queue with, since | ||
| # RabbitMQ rejects redeclaring an existing queue with different arguments. | ||
| max_priority=5, |
There was a problem hiding this comment.
is it necessary to pass max_priority here? What happens if you leave the argument out?
|
|
||
|
|
||
| PRIORITY_QUEUES = {"imaging-primary", "imaging-secondary"} | ||
| MAX_QUEUE_PRIORITY = 5 |
There was a problem hiding this comment.
is there any harm in also setting the max-priority for the anonymisation queue? It would make it a priority queue, but I assume there's a default priority so we wouldn't need to pass it in or have a way to override it. Only because there's a fair bit of config / logic needed throughout the code to make the anonymisation queue a non-priority queue
There was a problem hiding this comment.
Yeah it might be worth leaving in, the original issue stated to leave it out but it has made things more complicated.
Yeah a future PR would be good, I think it would be easier to switch from sync to async later on as more could be combined but having the structure for sync is maybe useful to include for now |
stefpiatek
left a comment
There was a problem hiding this comment.
Thanks Ruaridh, looking good to me. A couple of questions and a suggestion for documentation
|
|
||
|
|
||
| class PixlConsumer(PixlQueueInterface): | ||
| class PixlConsumer[PixlMessage: ImagingRequestMessage](PixlQueueInterface): |
There was a problem hiding this comment.
Love to see some type generics
There was a problem hiding this comment.
Though we're not subclassing this, so might be worth just using the exact ImagingRequestMessage type within the class
I don't think we do want this, because the de-id is an intensive process we'd probably want to spawn child processes to handle it so we're not bound by the same process |
Description
Fixes PIX-68
Fixes #650: Adds new queue "anonymisation" in
pixl_core/anon_queuewithout async functionality, withinorthancadds anon_queue (to replace POST call which hasn't been removed yet), adds "anonymisation" to queue_to_count within thecliand adds corresponding tests withincliandpixl_core.Type of change
Please delete options accordingly to the description.
Suggested Checklist
mainbranch.squash and merge