🏗️ Architecture: What is the propagation cost of changing a sync method to as...

Date: 2026-03-27
Time: 18:55:15 UTC
Session: gspace1-276.15
Agent: angular
Confidence: 88%
Status: ✅ Documented

📋 Decision Context

Question:

What is the propagation cost of changing a sync method to async in a deeply-used service?

Task: Wire 2B: Trust annotation on tool registry

🎯 Decision Made

Chosen:

getToolsForUser() in tool-registry.service.ts was changed from sync to async to support trust annotation (which requires await getScore()). This required updating all callers in agent-loop.service.ts and test mocks from mockReturnValue to mockResolvedValue.

Options Considered:

1. Make getToolsForUser async (chosen — propagates to callers)
2. Separate async annotateTools step (cleaner but more call sites)
3. Pre-cache trust scores at session start (best perf, more complexity)

💭 Reasoning

Trust annotation requires async getScore() per tool. Three alternatives: (1) make getToolsForUser async (chosen — clean but propagates), (2) add a separate async annotateTools step after sync getToolsForUser (cleaner separation but callers must call two methods), (3) pre-cache trust scores at session start and use sync lookup (best perf but requires cache invalidation). Chose option 1 because the callers (agent-loop) are already async and the propagation was contained to 2 callers + 2 test files. Early warning: any future sync consumer of getToolsForUser will get a compilation error (Promise not assignable to ToolDefinition[]), which is actually a good thing — it forces awareness of the trust annotation path.

📁 Files Involved

• APIs/backend-vitto-api/src/app/tools/tool-registry.service.ts
• APIs/backend-vitto-api/src/app/engine/agent-loop.service.ts

🔗 Related

• Decision ID: dev_1774637715760_el0szto
• Session: 276
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation