RI-7632: rework statistics for api/v2 client #5356
Conversation
Code Coverage - Integration Tests
|
Code Coverage - Backend unit tests
Test suite run success3077 tests passing in 292 suites. Report generated by 🧪jest coverage report action from 4eda927 |
Code Coverage - Frontend unit tests
Test suite run success5556 tests passing in 704 suites. Report generated by 🧪jest coverage report action from 4eda927 |
…2-rdi-api-v2-statistics-rework-v2-client
ArtemHoruzhenko
requested review from
DimoHG,
KrumTy,
dantovska,
pawelangelow,
pd-redis and
valkirilov
as code owners
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
|
|
||
| describe('transformMetricsCollectionResponse', () => { | ||
| const mockProcessorMetrics: ProcessorMetricsResponse = { | ||
| name: 'processor_metrics' as any, |
There was a problem hiding this comment.
Type definitions require bypassing with type casts
Low Severity
The ComponentMetricsCollections enum defines values with hyphens ('processor-metrics', 'collector-metrics'), but test mocks use underscores ('processor_metrics', 'collector-source_metrics'), requiring as any casts at lines 101, 180, and 226 to bypass type checking. This suggests the type definitions don't match the actual API response format or are unnecessarily strict, reducing type safety.
Additional Locations (1)
| @@ -0,0 +1,90 @@ | |||
| export enum ComponentMetricsCollections { | |||
| processorMetrics = 'processor-metrics', | |||
There was a problem hiding this comment.
nit: Very very minor, but just for consistency - in most places we use capitalized enums, so better to stick to it.
| export interface ProcessorMetricsResponse extends ComponentMetricsResponse { | ||
| name: ComponentMetricsCollections.processorMetrics; | ||
| metrics: { | ||
| processing_performance: { |
There was a problem hiding this comment.
I didn't compare the interfaces between v1 and v2, I just wonder whether we have matching parts or they're complete independant from each other?
Because, if we have matching sub-parts, maybe we don't have to redeclare them here again?
What
This PR implements the RDI statistics functionality for the API v2 client, adding support for fetching and transforming statistics data from RDI API v2 endpoints.
Key Changes
Backend (API)
New Statistics Client Methods:
getStatistics()method toApiV2RdiClientfor fetching statistics from RDI API v2Statistics Transformers:
RdiStatisticsTransformerto convert API v2 responses to internal DTOsDTOs and Interfaces:
Testing
ApiV2RdiClient.getStatistics()RdiStatisticsTransformerTechnical Decisions
Transformer Pattern: Used a dedicated transformer class to separate API response parsing from business logic, making the code more maintainable and testable
Type Safety: Defined strict TypeScript interfaces for API v2 responses to catch type mismatches early
Error Handling: Implemented robust error handling to gracefully handle API failures and malformed responses
Separation of Concerns: Kept the client focused on HTTP communication while delegating transformation logic to specialized transformers
Dependencies
This PR builds on top of:
Integration
The statistics client integrates with:
RdiClientProvider- uses this client to fetch statisticsTesting
Automation Tests
ApiV2RdiClient.getStatistics()methodRdiStatisticsTransformerManual Testing
Test Coverage
Note
Introduces API v2 statistics support and converts v2 metrics into existing statistics sections.
getStatistics()toApiV2RdiClientusingGET api/v2/pipelines/{name}/metric-collections, returningRdiStatisticsResultwith transformed sectionsmetrics-collections.response.ts) and exports in responses indextransformMetricsCollectionResponse(reuses v1 transformers) and extendedtransformProcessingPerformance(addstransform_time_avg,write_time_avg)RdiUrlV2.GetMetricsCollectionsin constantsWritten by Cursor Bugbot for commit 4eda927. This will update automatically on new commits. Configure here.