dev #71

root · 2026-06-01T18:52:37+03:00

root commented

2026-06-01 18:52:37 +03:00

No description provided.

root added 11 commits 2026-06-01 18:52:38 +03:00

fix(api): emex source-db lookup uses catalogCode+gid, not SSD 41acff2ab2

Initial design routed emex lookups through vehicles.rawData.ssd → dump vehicles
→ vehicle_parts. Smoke test against prod ssd values: 0 / 10 matched. EMEX
regenerates the SSD on every decode session, so sase's stored SSD never
matches the SSD the dump scraper recorded for the same physical vehicle.

Pivot to a catalog-wide bridge that actually works:
  catalogs.code    ↔ vehicles.rawData.catalogCode  (e.g. "RENAULT201910")
  part_groups.group_id ↔ categories.externalId    (e.g. "11754")
  → parts via vehicle_parts.group_id (dump's parts.group_id is 100% NULL)

Verified coverage on prod's 8287 unique (catalogCode, gid) pairs: 25/26
catalog codes resolve, 7178 pairs hit a part_group (87%), 5919 of those
return actual parts via vehicle_parts (~71% net). Tradeoff: returns all
parts in the (catalog, group) across every variant in the catalog, so the
result is slightly noisier than the live per-vehicle scrape. Acceptable —
parts overlap heavily and the upstream-call savings outweigh the noise.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

chore(api): bump source-db hit logs to log level for dev verification 94117dd75d

Easier to see [source-db hit pcat/emex] lines while dev verifies coverage.
Can be downgraded back to debug once we've measured prod hit rates.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

chore(deploy): expose CATALOG_SOURCE_DB_* env to api+worker via compose 506f11d636

Coolify env vars only reach docker-compose services that explicitly reference
them via ${VAR}. Adding CATALOG_SOURCE_DB_ENABLED + PCAT_SOURCE_DB_URL +
EMEX_SOURCE_DB_URL to both the api and worker `environment:` blocks so the
catalog-source-db lookup layer can pick them up. All three default empty/false
so this is a no-op until set in the Coolify env editor for an environment.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

chore(catalog-source): split per-source kill switches; default pcat off 3a3a7d3ebf

Verified 2026-06-01 against dev's 103 unique pcat carIds: the current pcat
dump's deep-scrape (7.978 cars with real parts data via schema_parts or
part_groups+part_group_items) targets a US/JDM-market subset — Toyota 2112,
Nissan 1508, Audi 1311, Chevy 1050, Hyundai 745. **None** of sase's TR-market
vehicles intersect that rich subset:

  - 18/103 sase carIds are in dump.cars at all (registry only)
  - 0/103 yield parts via Bridge A (schema_images → schema_parts)
  - 0/103 yield parts via Bridge B (part_groups → part_group_items)

Even the cars that match by exact carId (Fiat Doblo 368 schemas, Renault
Megane, Bravo 456 schemas) have only diagram metadata — no parts annotation.
The dump scraper finished tier-1 (catalog/model/car listing) and tier-2
(schema diagrams) for these, but stopped before tier-3 (parts annotation).

Under the strict "always correct OEM" constraint there is no safe pcat lookup
today. Disable it. The container stays up for future use cases (OEM cross-
reference search, alt-part matching) and so we can flip the env back without
a code change if a richer dump arrives.

EMEX stays on (its catalog-allowlist is the next step).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

feat(observability): browser Sentry SDK (gated on VITE_SENTRY_DSN)

QA Gate (P0/P1) / Test affected app (pull_request) Has been cancelled

Details

9f3eb0ff86

Sase frontend has Faro (RUM) and PostHog (product analytics) but no browser
error monitoring. A recent panel session investigation (panel insight
cmpv9q3ms004dfcphluw0z8bh — silent rage-clicks after parts_panel_viewed
with no API call) couldn't be confirmed or refuted from JS error data
because there was no JS error channel at all. This adds one.

- @sentry/react ^9 (dynamic import in lib/sentry.ts so the bundle only
  pays the SDK cost when DSN is configured)
- Init is gated on VITE_SENTRY_DSN — unset = no-op, no behaviour change
- Replay only fires on error (sessionSampleRate 0, onErrorSampleRate 1)
- KVKK: sendDefaultPii false, maskAllText + blockAllMedia on replay
- Builds emit hidden source maps so Sentry can de-minify traces while
  end users don't fetch the maps in the browser
- docker-compose.coolify.yml threads VITE_SENTRY_* through as build args
  (VITE_* must be build-time; runtime env never reaches a Vite bundle)

Wiring on the Coolify side is a separate manual step — set
VITE_SENTRY_DSN on the prod (ro48g…) and/or dev (jwgwkg…) app and
redeploy. Backend Sentry (NestJS) is unchanged.

Refs: Süper Panel docs/ARCHITECTURE.md, panel sentry-archive job.

Merge pull request 'feat(observability): browser Sentry SDK (gated on VITE_SENTRY_DSN)' (#68 ) from feat/sentry-browser into dev f4e74908b9

Reviewed-on: #68

fix(observability): regenerate pnpm-lock.yaml for @sentry/react c6d65e0a89

PR #68 added `@sentry/react ^9.0.0` to apps/web/package.json without
updating pnpm-lock.yaml — the merge deploy (zwso4wc44skscw8k0ocw8wwo)
failed at `pnpm install --frozen-lockfile`:

  ERR_PNPM_OUTDATED_LOCKFILE: specifiers in the lockfile don't match
  specifiers in package.json:
  * 1 dependencies were added: @sentry/react@^9.0.0

Regenerated with pnpm@10.29.3 (matches the Dockerfile activation).
Only +80 lines (the new sentry deps); no other importers touched.

fix(observability): regenerate pnpm-lock.yaml for @sentry/react (#69 ) ed3a777d87

fix(observability): whitelist Sentry ingest in CSP connect-src

QA Gate (P0/P1) / Test affected app (pull_request) Has been cancelled

Details

778931c880

The browser Sentry SDK initialised fine (DSN reached the bundle,
__SENTRY__ carrier registered) but envelope POSTs were silently
blocked by the existing CSP — `connect-src` didn't list any Sentry
host. Playwright verification on dev.sase.tr confirmed zero requests
to *.sentry.io even after a deliberate uncaught error.

Adds https://*.ingest.de.sentry.io (otolog org lives in the EU/de
region; this matches both the python and sase-web project DSNs).

Merge pull request 'fix(observability): whitelist Sentry ingest in CSP connect-src' (#70 ) from fix/sentry-csp-connect-src into dev c01987da7d

fix(catalog-source): gate emex parts behind allowlist (safety)

QA Gate (P0/P1) / Test affected app (pull_request) Has been cancelled

Details

3613caa072

The catalog-wide bridge in EmexSourceDbService.fetchCategoryParts was
measured against vehicle_parts on 2026-06-01 and found to return 7-114x
more parts than belong to the requesting vehicle, with 49-98 wrong OEM
codes per 100 served. That directly violates the project rule that the
user must never see a wrong OEM.

Per-catalog noiseRatio sample (catalog-wide / per-vehicle):
  RENAULT201910 51x | FFIAT84 45x | VOLVO201410 24x | MB201810 14x
  AU1587 8x | BMW202501 70x (+ gid namespace mismatch ETK vs numeric)
  GM_C201809 114x | MINI202501 12x | LRE201412 7x | MAZDA2020 54x
  GM_OP201809 dump has only 1 wildcard vehicle (unique_key="_") so the
  single Crossland X "owns" all 47k Opel parts — same firehose served
  to any Opel sub-model in sase prod.

All alternative bridges were proven dead:
  SSD eşleştirme        - session-bound, 0/91 sase SSDs match dump
  scrape_queue_v2.vehicle_ssd - same session SSD format
  api_cache replay      - table empty (0 rows)
  wizard_parameters     - table empty (0 rows)
  VIN direct            - no VIN column in dump
The only viable per-vehicle bridge is vehicles.unique_key reconstruction
from raw_data.parsedOptions, but sase currently stores the required 4
wizard fields on just 5/103 emex vehicles (all Renault). That work is
follow-up; this patch only stops the bleeding.

Change:
- Add EMEX_SOURCE_DB_ALLOWED_CATALOGS env (comma-separated, default "")
- EmexSourceDbService.fetchCategoryParts returns null unless catalogCode
  is in the allowlist. Empty allowlist = service is effectively off for
  parts, full fallthrough to live emex.
- Connection pool stays alive so the follow-up per-vehicle bridge /
  schema-only path can use it without flipping env.
- Boot logs warn loudly when connected with an empty allowlist.

Prod was never affected — CATALOG_SOURCE_DB_ENABLED was unset there. This
fixes dev branch behaviour (default-on since commit 3a3a7d3) and keeps
prod safe by default once main is promoted.

Files:
- packages/config/src/index.ts        env schema + audit notes
- apps/api/src/config/configuration.ts parse allowlist into string[]
- apps/api/src/integrations/catalog-source-db/emex-source-db.service.ts
  allowlist field, init logging, fetchCategoryParts gate, class doc
- docker-compose.coolify.yml          env injection for api + worker

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

root merged commit 4a5d200e42 into main

2026-06-01 18:52:42 +03:00

root referenced this issue from a commit

2026-06-01 18:52:43 +03:00

Merge pull request 'dev' (#71) from dev into main

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: root/sase.tr#71