Monorepo correctness and tooling inconsistencies

[RichardKryling]

Technical Debt & Correctness Issues Identified During Monorepo Review

Hi 👋 — while reviewing the Sprocket monorepo locally, I ran a focused analysis for correctness, stability, and tooling consistency (not feature work). I wanted to share a few findings that may be helpful for future cleanup or prioritization.

None of these are blockers individually, but several could impact scalability, reliability, or developer experience over time.

---

🔴 High Severity

1. Workspace Inconsistency: replay-parse-service

• The replay-parse-service (Python-based) exists in the repository and is referenced in docker-compose.yml
• However, it is not included in the root package.json workspaces list
• As a result, root-level workspace commands (npm install, npm run build --workspaces, etc.) silently ignore it

Notes

• This appears related to, but distinct from, the existing Import Replay Parse Service issue (Import Replay Parse Service #528)
• That issue focuses on integration/usage, whereas this is a tooling/build correctness concern

---

2. Potential Database Connection Exhaustion (saveSalaries)

Location: core/src/franchise/player/player.service.ts

• saveSalaries uses nested Promise.allSettled over large player payloads
• Each iteration performs multiple DB reads and writes
• There is no concurrency limit or batching

Risk

• Large bulk updates could overwhelm the database connection pool
• This could surface as intermittent production failures rather than deterministic bugs

---

3. RabbitMQ Resource Leak in Replay Parse Service

Location: microservices/replay-parse-service/src/main.py

• BaseTask.connect() creates new RabbitMQ Producer and Connection instances
• These connections are not explicitly closed
• connect() can be re-invoked when a producer disconnects

Risk

• Orphaned RabbitMQ connections accumulating over time
• Increased broker load and hard-to-diagnose message issues

---

🟡 Medium Severity

4. Inconsistent @types/node Versions Across Workspaces

Examples:

• common: ^17.0.13
• core: ^16.11.13
• clients/discord-bot: ^15.14.9

Impact

• Shared types from common may behave differently depending on consumer
• Subtle compile-time or runtime mismatches are possible

---

5. Duplicate Configuration Resolution Logic

Location: core/ormconfig.mjs

• Implements its own env/file-based secret resolution
• Overlaps with ConfigResolver from @sprocketbot/common

Impact

• Configuration behavior can differ between runtime services and CLI tooling
• Increases maintenance cost and cognitive load

---

6. Missing Rejection Handling in Some Async Calls

• Some async operations (e.g. analyticsService.send) are guarded with .catch
• Others (e.g. certain eventsService.publish calls) lack rejection handling

Risk

• Possible UnhandledPromiseRejection crashes under failure conditions

---

🔵 Low Severity / Optimization Opportunities

7. Inefficient Subscription Queries

• Some GraphQL subscription filters perform nested DB lookups inside Promise.all
• Functional, but potentially expensive under high-frequency subscriptions

---

8. Hardcoded Domain Constants

Examples:

• Hardcoded IDs such as game.id !== 7 for Rocket League

Impact

• Fragile if seed data or IDs change
• Makes future expansion more error-prone

---

Closing Notes

I’m happy to clarify any of these or help break them into follow-up issues if useful.
Posting this primarily for visibility and future cleanup planning — not as an urgent request.

Thanks for the work on the project 🙌