Repository navigation
chore: remove bullmq - #453
Conversation
WalkthroughRemoved the BullMQ-based job queue and worker; WebhookController now performs eReputation weighted-poll processing synchronously using VotingReputationService and MessageService. package.json deps Changes
Sequence Diagram(s)sequenceDiagram
participant Webhook as Webhook
participant Controller as WebhookController
participant VRS as VotingReputationService
participant MS as MessageService
participant Adapter as External Adapter
rect rgb(200,220,255)
note over Controller: Old (removed)
Webhook->>Controller: handlePoll()
Controller->>JobQueue: enqueuePollReputationJob()
JobQueue->>Worker: async process (worker handled reputation & messaging)
end
rect rgb(220,255,220)
note over Controller: New (inline)
Webhook->>Controller: handlePoll()
Controller->>Controller: processEReputationWeightedPoll()
Controller->>VRS: computeReputation(poll)
VRS-->>Controller: reputationResults
Controller->>Controller: transmitReputationResults()
Controller->>Adapter: sync results
Adapter-->>Controller: ack
Controller->>Controller: createReputationMessage()
Controller->>MS: persist system message
MS-->>Controller: created
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
💤 Files with no reviewable changes (2)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
platforms/eReputation-api/src/controllers/WebhookController.ts (3)
268-273: Fire‑and‑forget eReputation processing: behavior and reliability trade‑offsTriggering
processEReputationWeightedPoll(...)withoutawaitand only logging errors gives you non-blocking webhooks, but also:
- No retry/backoff if OpenAI/DB fails.
- No deduping/idempotency if the same poll is processed multiple times, which can emit repeated system messages and adapter updates.
- Work is lost if the process dies mid‑calculation (previously handled by the queue).
If you want to keep things simple but harden behavior, consider:
- Adding a lightweight idempotency guard keyed by
poll.id(e.g., short‑lived in‑memory set) to avoid concurrent duplicate runs.- Optionally wrapping this in a small internal “job runner” abstraction so you can later layer retries/metrics without re-touching controller logic.
Also applies to: 298-303
335-395: Minor cleanup: unused parameters and potential simplification
transmitReputationResultsreloadsVoteReputationResult,Poll, andGroupfrom the DB and never uses thepollandgroupparameters passed in. That’s harmless but slightly confusing.Two small cleanups you might consider:
- Drop the
poll/groupparameters from the signature, or actually use them to avoid some reloads.- If
adapter.handleChangeaccepts structured JSON, you may not needJSON.stringify(reloadedResult.results)(keep as‑is if the adapter explicitly expects a string).These are cosmetic and can be deferred.
397-424: System message generation is sound; consider batching user lookupsThe message text assembly and error handling look good and will produce a clear, human‑readable summary.
If groups can be large, you might later refactor the per‑user
await this.userService.getUserByEname(...)loop into a batched query (orPromise.all) to cut down on N+1 DB hits, but it’s fine to leave as‑is for now.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
platforms/eReputation-api/package.json(0 hunks)platforms/eReputation-api/src/controllers/WebhookController.ts(5 hunks)platforms/eReputation-api/src/index.ts(1 hunks)
💤 Files with no reviewable changes (1)
- platforms/eReputation-api/package.json
🧰 Additional context used
🧬 Code graph analysis (2)
platforms/eReputation-api/src/index.ts (1)
platforms/eReputation-api/src/controllers/WebhookController.ts (1)
WebhookController(16-425)
platforms/eReputation-api/src/controllers/WebhookController.ts (1)
platforms/eReputation-api/src/services/VotingReputationService.ts (1)
VotingReputationService(8-506)
🔇 Additional comments (2)
platforms/eReputation-api/src/index.ts (1)
55-55: Controller wiring matches new constructor signatureInstantiating
WebhookControllerwithout arguments aligns with the new no-arg constructor and removal of the queue service; nothing else needed here.platforms/eReputation-api/src/controllers/WebhookController.ts (1)
314-333: Inline eReputation pipeline is coherent and well‑guardedThis helper cleanly:
- Bails out when
groupId/group.charterare missing.- Delegates calculation + persistence to
VotingReputationService.- Separates concerns by delegating transmission and messaging.
The control flow and guards look correct for the updated design.
| import { VotingReputationService } from "../services/VotingReputationService"; | ||
| import { MessageService } from "../services/MessageService"; |
There was a problem hiding this comment.
Eagerly constructing VotingReputationService can make OPENAI mandatory for the API to start
Because VotingReputationService’s constructor throws when OPENAI_API_KEY is missing, new WebhookController() will now fail at process startup in environments that don’t configure that key (e.g., local/dev or tests that don’t need eReputation). Previously, this dependency was likely isolated to the worker/queue path.
Consider either:
- Lazily instantiating
VotingReputationServiceinsideprocessEReputationWeightedPoll(on first use), or - Making the service tolerate a missing key and no-op eReputation, so the rest of the API can still boot.
This keeps the “remove bullmq” goal while avoiding a new hard startup dependency on OpenAI.
Also applies to: 12-12, 21-22, 25-25, 30-31
🤖 Prompt for AI Agents
In platforms/eReputation-api/src/controllers/WebhookController.ts (lines 6-7,
12, 21-22, 25, 30-31): the controller currently eagerly constructs
VotingReputationService which throws if OPENAI_API_KEY is missing, preventing
app startup; change to lazily instantiate VotingReputationService only inside
processEReputationWeightedPoll (create on first use) or update the service to
detect a missing OPENAI_API_KEY and become a no-op implementation (return early
or mock methods) so construction won’t throw; ensure all places that reference
the eager instance use the lazily-created instance (guard with a null check and
create if undefined) and add a clear comment about the lazy/no-op behavior so
non-eReputation environments can boot without OpenAI configured.
There was a problem hiding this comment.
nack, works as intended
There was a problem hiding this comment.
@coodos, understood! Thanks for clarifying that the eager instantiation and the OPENAI_API_KEY requirement at startup are intentional design decisions.
✏️ Learnings added
Learnt from: coodos
Repo: MetaState-Prototype-Project/prototype PR: 453
File: platforms/eReputation-api/src/controllers/WebhookController.ts:6-7
Timestamp: 2025-11-20T12:00:02.259Z
Learning: In platforms/eReputation-api/src/controllers/WebhookController.ts, the eager instantiation of VotingReputationService in the constructor (which requires OPENAI_API_KEY at startup) is intentional behavior and works as intended.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
Description of change
Remove BullMQ
Issue Number
Type of change
How the change has been tested
Change checklist
Summary by CodeRabbit
Chores
Improvements
✏️ Tip: You can customize this high-level summary in your review settings.