Skip to navigation
Research and SpikesServices Evaluation

Status check Service Evaluation

This document provides a comprehensive evaluation of the fluxx-statuscheck microservice as part of the code review and assessment process. User Story 729004 SPIKE: Evaluate the Status Check Service

Suggested changes and potential enhancements have been identified for each category. The items have been marked with Severity to indicate importance.

Endpoints Overview

All endpoints are documented in OpenAPI 3.0.3 format with Swagger UI available at /docs.

Status Check Endpoints

MethodPathPurposeStatusDocumented
GET/v1/files/{id}Get status history for specific fileImplementedYes
GET/v1/Get files recently active (1 month)ImplementedYes
GET/v1/rejectedGet rejected files (12 months)ImplementedYes
GET/openapi.yamlOpenAPI specification in YAMLImplementedYes
GET/versionGet service version and commit hashImplementedPartial*
GET/healthHealth check endpointImplementedYes

Implementation Files:

  • Routes: src/routes/v1/status.ts, src/routes/version.ts, src/api/openapi/openapi.route.ts

  • Controllers: src/controllers/statusController.ts, src/controllers/openApiController.ts

  • Services: src/services/file/fileStatusService.ts, src/services/file/fileStatusHistoryService.ts

  • Schemas: src/routes/schemas/status.schemas.ts

Message Handler Endpoints (Service Bus)

TopicSubscriptionPurposeStatusHandler
validated-filestatus-validated-fileProcess validated filesImplementedvalidatedFileHandler.ts
accepted-filestatus-accepted-fileProcess accepted filesImplementedacceptedFileHandler.ts
problemstatus-problem-fileProcess file problemsImplementedproblemHandler.ts

Implementation Files:

  • Message Receiver: src/subscriptions/messageReceiver.ts

  • Handlers: src/subscriptions/validatedFileHandler.ts, src/subscriptions/acceptedFileHandler.ts, src/subscriptions/problemHandler.ts

  • Service: src/services/topicService.ts

Utility Endpoints

MethodPathPurposeStatusDocumented
GET/docsSwagger UI documentationImplemented (Framework)Yes
GET/healthHealth check endpointImplementedYes

*Note: /version response schema not included in OpenAPI spec (see Critical Issues)

Possible Enhancements

No.SeverityDescription
1MediumAdd integration tests for the complete message consumption flow (Service Bus → Database → Query endpoint) to ensure end-to-end data consistency
2MediumAdd contract tests for message schema validation to ensure rejected files are properly handled
3MediumAdd next step to message received when its moved to dead letter

Code

Potential optimizations and improvements have been included in the table below.

No.SeverityCategoryDescriptionReferences
1MediumError HandlingMessage processing failures are logged but messages are blindly abandoned without distinguishing between transient and permanent failures. Transient errors (network timeout) should retry automatically, but permanent errors (invalid message schema) should be dead-lettered immediately. Consider implementing error classification with conditional retry logic.src/subscriptions/messageReceiver.ts lines 56-77
2MediumData AccessImplement repository pattern. This couples services to database implementation and makes unit testing difficult. Consider introducing IFileStatusRepository interface.src/services/file/fileStatusService.ts, src/services/problem/problemService.ts
3MediumConfigurationConfiguration keys are scattered across code using string-based app.lookup() calls. While ENV_KEYS constant exists, it’s not enforced. Consider creating a config validation function that verifies all required keys exist at startup.src/index.ts, src/services/topicService.ts, src/internal/createSqlConnectionOptions.ts
4MediumTest CoverageNo service tests exist for Service Bus message consumption. Unit tests cover individual services but end-to-end flow (message received → database update → query returns update) is untested. Add service tests in test/service/.test/service/ (directory exists but empty)
5LowCode OrganizationSchema file src/routes/schemas/status.schemas.ts contains 186 lines with multiple endpoint schemas mixed together. Consider splitting into separate files: getFileStatusByIdSchema.ts, getLatestFileStatusesSchema.ts, getRejectedFilesSchema.ts.src/routes/schemas/status.schemas.ts
6LowData IntegrityFile status history response is missing the id field that is documented in OpenAPI spec as required. Clients expecting history[].id will fail to parse responses correctly. Must include FileStatusHistoryId in response.src/services/file/fileStatusHistoryService.ts, src/routes/schemas/status.schemas.ts

Documentation

Below are the suggested changes to the documentation.

No.DocumentSeverityDescriptionReferences
1Code CommentsLowDocument reason for consistent use of ISO-8601 timestamps in all responses. Mention timezone handling (all stored as UTC).src/services/file/fileStatusService.ts
2Workflow DiagramLowCreate a workflow diagram for message handling 

Dependencies Analysis

Production Dependencies Review

PackageVersionUsageStatusRecommendation
@azure/identity4.13.0Managed identity authUsedKeep
@azure/service-bus7.9.5Message queueUsedKeep
@azure/storage-blob12.28.0Blob storageUnusedRemove
@fastify/awilix7.0.0DI integrationUsedKeep
@fastify/multipart9.2.1File uploadsUnused*Review
awilix12.0.5DI containerUsedKeep
framework-nodejs-*2.0.1CLA frameworkUsedKeep

*@fastify/multipart not used in current code but may be needed for future file upload feature

Unused Dependency

Action Required: Remove @azure/storage-blob from package.json

  • Imported but never instantiated

  • No Blob Storage operations in code

  • Should add to .npmrc or consider for future use

Summary

The Status Check Service is functionally complete with all core endpoints working correctly.

Main areas to address:

  • Fix file status history response to include required id field

  • Implement error classification for proper message retry behavior

  • Introduce repository pattern for better testability

  • Add service tests for end-to-end message flow validation

  • Improve error handling with domain-specific exception types

  • Create a workflow diagram for message handling