mosaic/stack
1
0
Fork 0
Code Issues 10 Pull Requests Actions Packages Projects Releases 2 Wiki Activity

Add explicit return types to service methods #197

New Issue
Closed
opened 2026-02-02 17:27:09 +00:00 by jason.woltje · 0 comments
jason.woltje commented 2026-02-02 17:27:09 +00:00
Owner
Copy Link

Problem

Multiple service methods use complex return types like Awaited<ReturnType<typeof this.prisma...>> which obscures actual return types and makes code harder to maintain.

Locations

  • apps/api/src/runner-jobs/runner-jobs.service.ts:336-375
  • apps/api/src/coordinator-integration/coordinator-integration.service.ts (multiple methods)
async updateStatus(
  id: string,
  workspaceId: string,
  status: RunnerJobStatus,
  data?: { result?: unknown; error?: string }
): Promise<Awaited<ReturnType<typeof this.prisma.runnerJob.update>>> {
  // ❌ Return type is unreadable
}

Impact

  • Violates Quality Rails requirement for explicit return types
  • IDE autocomplete less helpful
  • Makes refactoring risky
  • Harder to understand method contracts

Acceptance Criteria

  • Define explicit interfaces for all return types
  • Replace all Awaited<ReturnType<...>> patterns
  • Export interfaces from module index
  • Update method signatures
  • Verify type safety maintained
  • Document return type conventions

Implementation

// Define explicit interface
interface JobUpdateResult {
  id: string;
  workspaceId: string;
  status: RunnerJobStatus;
  result?: unknown;
  error?: string;
  updatedAt: Date;
}

// Use in method
async updateStatus(
  id: string,
  workspaceId: string,
  status: RunnerJobStatus,
  data?: { result?: unknown; error?: string }
): Promise<JobUpdateResult> {
  const updated = await this.prisma.runnerJob.update({...});
  return updated as JobUpdateResult;
}

Files to Update

  • runner-jobs.service.ts
  • coordinator-integration.service.ts
  • job-steps.service.ts
  • job-events.service.ts

References

M4.2-Infrastructure verification report (2026-02-02)
Quality Rails guideline

## Problem Multiple service methods use complex return types like `Awaited<ReturnType<typeof this.prisma...>>` which obscures actual return types and makes code harder to maintain. ## Locations - apps/api/src/runner-jobs/runner-jobs.service.ts:336-375 - apps/api/src/coordinator-integration/coordinator-integration.service.ts (multiple methods) ```typescript async updateStatus( id: string, workspaceId: string, status: RunnerJobStatus, data?: { result?: unknown; error?: string } ): Promise<Awaited<ReturnType<typeof this.prisma.runnerJob.update>>> { // ❌ Return type is unreadable } ``` ## Impact - Violates Quality Rails requirement for explicit return types - IDE autocomplete less helpful - Makes refactoring risky - Harder to understand method contracts ## Acceptance Criteria - [ ] Define explicit interfaces for all return types - [ ] Replace all `Awaited<ReturnType<...>>` patterns - [ ] Export interfaces from module index - [ ] Update method signatures - [ ] Verify type safety maintained - [ ] Document return type conventions ## Implementation ```typescript // Define explicit interface interface JobUpdateResult { id: string; workspaceId: string; status: RunnerJobStatus; result?: unknown; error?: string; updatedAt: Date; } // Use in method async updateStatus( id: string, workspaceId: string, status: RunnerJobStatus, data?: { result?: unknown; error?: string } ): Promise<JobUpdateResult> { const updated = await this.prisma.runnerJob.update({...}); return updated as JobUpdateResult; } ``` ## Files to Update - runner-jobs.service.ts - coordinator-integration.service.ts - job-steps.service.ts - job-events.service.ts ## References M4.2-Infrastructure verification report (2026-02-02) Quality Rails guideline
jason.woltje added this to the M4.2-Infrastructure (0.0.4) milestone 2026-02-02 17:27:09 +00:00
jason.woltje added the p2apiapi labels 2026-02-02 17:27:09 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
ai
AI/LLM integration
 api
Backend/API work
 api
auth
Authentication
 database
database
Database/schema work
 devops
Docker/deployment
 docs
Documentation
 frontend
graph
knowledge-module
migration
Data migration
 orchestrator
Orchestrator service (apps/orchestrator/)
 p0
Critical priority
 p1
High priority
 p2
Medium priority
 p3
Low priority
 performance
Performance work
 phase-1
phase-2
phase-3
phase-4
phase-5
plugin
MoltBot plugin work
 search
security
Security-related
 setup
Initial setup
 testing
Testing/QA
 web
Frontend work
No Label api api p2
Milestone
No items
No Milestone M4.2-Infrastructure (0.0.4)
Projects
Clear projects
No project
Assignees
Clear assignees
jason.woltje
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaic/stack#197
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?