Repository navigation
feat: Agoda.DevExTelemetry full-stack implementation - #1
Merged
Merged
Conversation
Multi-agent parallel implementation of the DevEx Telemetry dashboard: - Agent 1: Project scaffold, entities, DTOs, interfaces, configs - Agent 2: Ingest controllers (9 POST endpoints), normalization services - Agent 3: Dashboard read API (6 GET endpoints), view models, queries - Agent 4: React frontend (3 dashboards, filters, charts, tables) - Agent 5: Integration tests (63) and unit tests (38), all passing Backend: .NET 10, EF Core SQLite, Agoda.IoC DI Frontend: React 19, Tremor, Recharts, TanStack Table, Vite 8, Tailwind 3 Build verified: dotnet build (0 errors), dotnet test (101 passed), npm run build (tsc + vite, 0 errors) Made-with: Cursor
Add GitHub Actions build workflow (backend + frontend parallel jobs) and Azure App Service deployment workflow triggered on main branch push. Made-with: Cursor
Remove push trigger from build workflow to avoid duplicate runs. Deploy workflow already covers push-to-main. Made-with: Cursor
Replace template boilerplate with actual architecture, endpoints, development setup, and deployment info. Made-with: Cursor
Made-with: Cursor
Made-with: Cursor
Made-with: Cursor
- Add 71 Playwright component tests covering all Layer 2 components, utility functions, and Layer 3 pages with API mocking - Set up ESLint with typescript-eslint, react-hooks, and react-refresh plugins - Set up Prettier with eslint-config-prettier integration - Add Prettier check and ESLint steps to CI build workflow - Format all source files with Prettier Made-with: Cursor
Cache ~/.nuget/packages in both build and deploy workflows using actions/cache@v4. The deploy workflow (push to main) populates the cache, and PR branches fall back to it via restore-keys. Made-with: Cursor
joeldickson
commented
Mar 22, 2026
joeldickson
left a comment
joeldickson
left a comment
Contributor
Author
There was a problem hiding this comment.
Completed agent-6 review against issue #224 criteria (correctness, missing tests, performance/concurrency, API contract alignment). I left inline comments for concrete issues that should be addressed before merge:
- Platform filtering is mapped to wrong fields in backend query logic.
- Frontend/backed query parameter contract mismatch (
projectNamevsProject, unsupporteddateRange). - UI "platform" filter currently populated from metric types.
- Duplicate-ID ingest behavior is implicit and can surface as 500.
- Numeric parsing allows silent bad data paths (e.g. malformed
timeTaken). - Cleanup timer can overlap async runs and conflict with SQLite writes.
- Malformed JUnit XML is treated as success instead of client error.
Please also add integration tests for each of these paths to prevent regressions.
Add toHaveScreenshot() assertions to all component and page specs: - 13 screenshot tests for Layer 2 components (StatCard, ChartCard, PageHeader, DashboardGrid, AppShell, EnvironmentToggle, GlobalFilters, DataTable in various states) - 4 screenshot tests for Layer 3 pages (TestRunDashboard, TestRunDetail, ApiBuildDashboard, ClientsideBuildDashboard) - Baseline PNG snapshots committed for Linux/Chromium Made-with: Cursor
- GlobalFilters: use options.platforms instead of options.metricTypes for the Platforms multi-select, so the UI label matches the data source - useFilters: send `project` (not `projectName`) and convert dateRange to explicit `from`/`to` ISO timestamps so the backend actually filters - client.ts: align FilterParams fields (project, from, to) and add platforms to FilterOptions - Update mock data and spec fixtures to include platforms array Made-with: Cursor
- GlobalFilters: source platforms from `options.platforms` instead of `options.metricTypes` to fix semantic mismatch - useFilters: send `project` (not `projectName`) and convert `dateRange` to explicit `from`/`to` ISO dates to match backend FilterParams - DataCleanupService: switch from Timer/IHostedService to BackgroundService/PeriodicTimer to prevent overlapping cleanup runs - Add `platforms` field to frontend FilterOptions and test fixtures Made-with: Cursor
- DashboardService: filter by Platform instead of TestRunner/MetricType - DotnetController: use InvariantCulture parsing, reject non-finite values - JUnitXmlParser: return JUnitXmlParseResult with error info - IngestService: idempotent duplicate-id handling with AnyAsync check - FilterService/FilterOptionsViewModel: expose distinct platform values Made-with: Cursor
joeldickson
commented
Mar 22, 2026
joeldickson
left a comment
joeldickson
left a comment
Contributor
Author
There was a problem hiding this comment.
Second-pass review completed after latest push.
Most previously reported issues are fixed (platform mapping in backend filters, query naming alignment, XML parse failure handling, cleanup timer overlap mitigation, platform options source).
Remaining issues are primarily:
- multi-select platform serialization vs backend equality filtering,
- API/Clientside table scoping params not consumed by backend,
- duplicate-ID ingest behavior still implicit (likely 500 path),
- one-type-per-file convention deviation in JUnit parser file.
Inline comments added for each with suggested fix directions.
- Support comma-separated platform filter values in backend (split CSV server-side) - Add BuildCategory filter to FilterParams and ApplyBuildMetricFilters - Frontend hooks now send buildCategory instead of metricType for page scoping - Extract JUnitXmlParseResult to own file per one-type-per-file convention Made-with: Cursor
Made-with: Cursor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Test plan
dotnet build— 0 errors, 0 warningsdotnet test— 63 passed (integration) + placeholder unit testsnpm run build(tsc + vite) — success