Goal
Investigate cold-start and per-instance overhead caused by startup work, repeated client creation, and service construction patterns.
Why this matters
Some storage clients and configuration setup are recreated inside constructors or feature classes rather than being fully centralized through DI. That adds avoidable work at startup and on new instances.
Relevant code areas
- feedbackfunctions\Program.cs
- feedbackfunctions\Reports\ReportFunctions.cs
- feedbackfunctions\Reports\ReportProcessorFunctions.cs
- feedbackfunctions\Reports\AdminReportProcessorFunction.cs
- feedbackfunctions\Utils\ReportGenerator.cs
- FeedbackFlow.MCP.Local\Program.cs
- FeedbackFlow.MCP.Remote\Program.cs
Investigation tasks
- Identify BlobServiceClient, BlobContainerClient, TableServiceClient, and TableClient creation patterns that should move fully into DI.
- Review repeated configuration rebuilding or environment setup done in constructors.
- Quantify startup work such as InitializeTablesAsync and other boot-time operations.
- Determine which startup work should remain synchronous versus be pre-provisioned or deferred.
- Evaluate whether backend-adjacent MCP services share similar client or timeout patterns worth standardizing.
Deliverables
- A startup and initialization cost inventory.
- A low-risk DI/client-centralization plan.
- Recommendations for any startup work that should be moved, cached, or pre-provisioned.
Acceptance criteria
- We understand the main cold-start and construction-time costs.
- We have a concrete plan to remove repeated client/setup overhead without changing behavior.
Goal
Investigate cold-start and per-instance overhead caused by startup work, repeated client creation, and service construction patterns.
Why this matters
Some storage clients and configuration setup are recreated inside constructors or feature classes rather than being fully centralized through DI. That adds avoidable work at startup and on new instances.
Relevant code areas
Investigation tasks
Deliverables
Acceptance criteria