fix: service integration tests fix (#11598)

.adr/0000-template.md

@@ -1,17 +0,0 @@
-# Title
-
-## Status
-
-What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?
-
-## Context
-
-What is the issue that we're seeing that is motivating this decision or change?
-
-## Decision
-
-What is the change that we're proposing and/or doing?
-
-## Consequences
-
-What becomes easier or more difficult to do because of this change?

.adr/0001-record-architecture-decisions.md

@@ -1,30 +0,0 @@
-# Recording Architecture Decisions
-
-## Status
-
-Proposed
-
-## Context
-
-At SigNoz, architecture decisions are stored across internal communication channels, Notion, GitHub Issues, or directly
-in PR comments and code.
-
-When we need to understand the reasoning behind a large change or a specific decision in the codebase, finding it is
-difficult because we must search across many different places.
-
-## Decision
-
-Instead of storing architecture decisions outside this codebase, we will use the structure proposed
-by [ADR](https://github.com/architecture-decision-record/architecture-decision-record).
-
-This is the first decision being stored, alongside [0000-template.md](./0000-template.md) which serves as the template
-for new decisions.
-
-The current template is basic and inspired
-by [Michael Nygard's template](https://github.com/architecture-decision-record/architecture-decision-record/blob/main/locales/en/templates/decision-record-template-by-michael-nygard/index.md).
-Over time, we can improve or change it to better fit our needs.
-
-## Consequences
-
-We can still store internal discussions or private matters in our internal communication channels. However, with this
-approach, we have a single place to look for decisions about the codebase.

.adr/0002-migrate-to-oxlint.md

@@ -1,61 +0,0 @@
-# Migrate from ESLint to Oxlint
-
-## Status
-
-Accepted
-
-## Context
-
-Current implementation (02/17/2025) uses ESLint v7 (latest is v10):
-
-- **Dependencies**: 12 (without eslint itself)
-- **Execution time**: 113s locally, 185s on CI
-- **Memory usage**: 3472mb
-
-Our pain with Eslint is caused by the integration of it when create a commit, causing the git commit to take multiple
-seconds instead of being instant or feel instant.
-
-### Requirements for new tooling
-
-- Fast execution (primary goal)
-- Community/plugin support
-- IDE support (Cursor/VSCode, JetBrains)
-- Fewer dependencies (install speed, reduced threat vector)
-
-### Alternatives evaluated
-
-| Feature           | ESLint | Biome | Oxlint |
-|-------------------|--------|-------|--------|
-| Lint Speed        | 195s   | 13s   | 6s     |
-| Format Speed      | 20s    | 0.5s  | 1.3s   |
-| Type-aware        | Yes    | Yes   | Yes*   |
-| Plugin Support    | Yes    | No**  | Yes    |
-| Dependencies      | 12     | 1     | 6      |
-| Replaces Prettier | No     | Yes   | Yes*** |
-
-\* Type-aware via tsgolint (uses Go-based TypeScript compiler)
-\** Biome uses GritQL for custom rules
-\*** Via oxfmt
-
-## Decision
-
-Migrate to Oxlint.
-
-References:
-- https://app.notion.com/p/signoz/Linting-Formatting-30cfcc6bcd1980a7bb47f04a41e67c21#30cfcc6bcd1980d28398c2fd8bcb53fb
-
-### Rationale
-
-1. **VoidZero ecosystem alignment**: Oxlint is part of Oxc project under VoidZero initiative (includes Vite, Vitest,
-   Rolldown). Future migration to Vite benefits from consistent tooling.
-
-2. **Performance**: Fastest option at 6s vs 195s (32x improvement). CI time: best among alternatives.
-
-3. **JS plugin support**: Custom rules possible without learning GritQL. Example: `signoz/no-zustand-getstate-in-hooks`
-   rule already implemented.
-
-## Consequences
-
-- **Development speed**: 32x faster linting (6s vs 195s)
-- **CI time**: Significant reduction in pipeline duration
-- **Memory usage**: Lower footprint than ESLint

.adr/0003-migrate-to-pnpm.md

@@ -1,63 +0,0 @@
-# Migrate from Yarn to pnpm
-
-## Status
-
-Accepted
-
-## Context
-
-Yarn install time is one of the slowest part of the CI, around 108s locally or 120s on CI. Also, we are using v1 that is
-on maintenance mode since 2020, and [will eventually reach EOL](https://github.com/yarnpkg/yarn/issues/9062).
-
-### Requirements
-
-- Faster install times
-- Better CI performance
-- Reduced attack surface for supply chain attacks
-
-## Decision
-
-We decided to migrate to pnpm mostly due to the usage of this package manager already by
-our [Component Library](https://github.com/SigNoz/components). We had good experience and the performance was great.
-
-### Performance improvements
-
-| CI Job    | Yarn   | pnpm  | Diff     |
-|-----------|--------|-------|----------|
-| tsc/js    | 2m56s  | 1m21s | -95s     |
-| test/js   | 10m30s | 8m20s | -130s    |
-| fmt/js    | 2m25s  | 33s   | -112s    |
-| lint/js   | 2m56s  | 44s   | -130s    |
-| authz     | 11m9s  | 9m24s | -105s    |
-| openapi   | 2m41s  | 1m7s  | -94s     |
-| **Total** |        |       | **-11m** |
-
-Install time: 108s → 16s (5.8x faster)
-
-### Security hardening
-
-Added `pnpm-workspace.yaml` with minimum release age:
-
-```yaml
-trustPolicy: no-downgrade
-minimumReleaseAge: 2880 # 2d
-minimumReleaseAgeStrict: true
-minimumReleaseAgeExclude:
-  - '@signozhq/*'
-blockExoticSubdeps: true
-```
-
-Prevents installing packages released less than 2 days ago — mitigates supply chain attacks where malicious code is
-pushed and quickly removed.
-
-## Consequences
-
-- Replace `yarn` commands with `pnpm` equivalents
-- `yarn add` → `pnpm add`
-- `yarn install` → `pnpm install`
-- `yarn run` → `pnpm run` (or just `pnpm <script>`)
-
-### References
-
-- PR #11158: https://github.com/SigNoz/signoz/pull/11158
-- PR #11274: https://github.com/SigNoz/signoz/pull/11274

tests/integration/tests/cloudintegrations/05_services.py

@@ -151,7 +151,6 @@ def test_get_service_details_without_account(
     assert "overview" in data, "Service should have 'overview' (markdown)"
     assert "assets" in data, "Service should have 'assets'"
     assert isinstance(data["assets"]["dashboards"], list), "assets.dashboards should be a list"
-    assert "telemetryCollectionStrategy" in data, "Service should have 'telemetryCollectionStrategy'"
     assert data["cloudIntegrationService"] is None, "cloudIntegrationService should be null without account context"
 
 
@@ -484,12 +483,12 @@ def test_enable_metrics_provisions_dashboards(
     assert isinstance(dashboards_in_service, list) and len(dashboards_in_service) > 0, "assets.dashboards should be non-empty after enabling metrics"
     provisioned_ids = set()
     for dash in dashboards_in_service:
-        assert "id" in dash, f"Dashboard entry missing 'id': {dash}"
+        assert "integrationDashboard" in dash, f"Integration dashboard entry missing"
         try:
-            uuid.UUID(dash["id"])
+            uuid.UUID(dash["integrationDashboard"]["id"])
         except ValueError as err:
-            raise AssertionError(f"Dashboard id '{dash['id']}' is not a UUID — dashboard was not provisioned") from err
-        provisioned_ids.add(dash["id"])
+            raise AssertionError(f"Dashboard id '{dash['integrationDashboard']['id']}' is not a UUID — dashboard was not provisioned") from err
+        provisioned_ids.add(dash["integrationDashboard"]["dashboardId"])
 
     # Assertion 2: Provisioned dashboard IDs are present in the DB
     with signoz.sqlstore.conn.connect() as conn:
@@ -539,7 +538,7 @@ def test_disable_metrics_deprovisions_dashboards(
         timeout=10,
     )
     assert get_svc_response.status_code == HTTPStatus.OK
-    provisioned_ids = {d["id"] for d in get_svc_response.json()["data"]["assets"]["dashboards"]}
+    provisioned_ids = {d["integrationDashboard"]["dashboardId"] for d in get_svc_response.json()["data"]["assets"]["dashboards"]}
     assert len(provisioned_ids) > 0, "Expected dashboards to be provisioned after enabling metrics"
 
     # Disable metrics