feat(workerchild): begin porting producer to FutureTrackingProducer - #744
Conversation
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 0700ac1. Configure here.
| task_produced_futures = TaskProducer.collect_futures() | ||
| task_produced_futures = ( | ||
| TaskProducer.collect_futures() | FutureTrackingProducer.collect_futures() | ||
| ) |
There was a problem hiding this comment.
Duplicate keys drop futures
Medium Severity
Merging TaskProducer.collect_futures() and FutureTrackingProducer.collect_futures() with dict | keeps only one set of futures when both registries share a producer name. TaskProducer entries are overwritten by FutureTrackingProducer, so those Kafka futures are never awaited and the activation can complete without them finishing or failing.
Reviewed by Cursor Bugbot for commit 0700ac1. Configure here.
There was a problem hiding this comment.
Not an issue, we won't share names during the cutover


In order to facilitate only needing a single producer abstraction in services that produce from both tasks and not-tasks, I'm going to replace
TaskProducerwith Arroyo'sFutureTrackingProduceradded in getsentry/arroyo#547.This PR begins the cutover by collecting producer futures from both
TaskProducerandFutureTrackingProducer. Once all instances ofTaskProducerin Sentry are switched over, I'll remove everything related toTaskProducer.