feat: add Kafka topic setup and recent spans polling endpoint #516
Conversation
…ove error handling
…sumer initialization
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #516 +/- ##
==========================================
- Coverage 59.29% 54.10% -5.19%
==========================================
Files 341 122 -219
Lines 17075 5205 -11870
==========================================
- Hits 10124 2816 -7308
+ Misses 6951 2389 -4562
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
|
||
| self.log.debug(f"Spans {response.trace_status}: {response.span_count} spans") | ||
| if response.trace_status == "queued" and response.span_count > 0: | ||
| # When using Kafka queue, we don't get database UUIDs back immediately |
There was a problem hiding this comment.
We should get some span_uuid from the initial add to queue, so shouldn't we be able to get some uuids back? If not, then even returning back the trace_id would be really useful, and I can always render the client using trace_id if we dont have uuid.
|
|
||
| return False | ||
|
|
||
| async def send_span(self, span_data: dict[str, Any], user_id: UUID) -> bool: |
There was a problem hiding this comment.
I am worried this class will get really bloated when we add more topics. These functions, send_span and send_spans_batch feel like they could be more generic.
We could take in a topic as an argument, some key, and some data.
Our KafkaService can depend on get_current_user so we don't need to pass in user_id.
What do you think?
No description provided.