learning_ai_common_plat/services
saravanakumardb1 191b81756d fix(platform-service): resolve 3 TS errors in /devops/info handler
The platform-service build was failing with 3 unrelated TS errors,
surfaced while running the Gitea outdated-package detector earlier
in this session:

  src/server.ts(18,8):   Cannot find module '@bytelyst/devops/server'
  src/server.ts(318,61): Property 'cosmosEndpoint' does not exist on type 'ProductIdentity'
  src/server.ts(321,42): Property 'platformServiceUrl' does not exist on type 'ProductIdentity'

Root causes (two distinct bugs):

1. Stale install. '@bytelyst/devops' was already declared as
   'workspace:*' in services/platform-service/package.json (line 24),
   but node_modules/@bytelyst/devops/ did not exist. Re-running
   'pnpm install' at the workspace root materialised the symlink.

2. Variable shadowing. In the GET /devops/info handler the code
   declared a local 'const config' from loadProductIdentity() that
   shadowed the module-level 'config' (env vars) imported from
   './lib/config.js' at line 112. The author then tried to read
   'config.cosmosEndpoint' and 'config.platformServiceUrl' off the
   ProductIdentity, where those keys never exist:

     ProductIdentity = {
       productId, displayName, licensePrefix, configDirName,
       envVarPrefix, bundleIdSuffix, packageName
     }

   The intended values live on the env config:
     config.COSMOS_ENDPOINT  (Zod-validated, required at boot)
     config.HOST + config.PORT (defaults '0.0.0.0' / 4003)

   There is no 'platformServiceUrl' field anywhere in the codebase —
   it only appeared in this single buggy line. Reconstructed as
   '\${HOST}:\${PORT}' which is the URL admins would use to reach
   this service for the devops/info diagnostic dashboard.

Fix (services/platform-service/src/server.ts:310-339):
  - Rename local 'const config' to 'const productIdentity' to break
    the shadowing.
  - Use productIdentity.productId for the devops productId field.
  - Use config.COSMOS_ENDPOINT (the env config) for the cosmos
    dependency health check URL.
  - Use `http://${config.HOST}:${config.PORT}` for the extra
    platformServiceUrl field.
  - Add a doc comment block explaining the two-config distinction
    so future contributors don't reintroduce the shadow.

Verified:
  pnpm --filter @lysnrai/platform-service build    OK (0 errors)
  pnpm --filter @lysnrai/platform-service test     1511/1512 pass

The 1 remaining failure (src/modules/products/cache.test.ts line 104,
'returns all cached products' expects 2 products but got 3) is a
PRE-EXISTING product-registry test drift on main, verified by
stashing this commit's changes and re-running the same test against
the unmodified tree. It will be addressed separately.
2026-05-23 12:46:10 -07:00
..
cowork-service chore(cowork-service): type test doubles 2026-05-04 15:25:43 -07:00
extraction-service chore(extraction): document sidecar dev alerts 2026-05-04 16:42:25 -07:00
mcp-server test(mcp-server): cover chronomind tool proxies 2026-05-18 09:33:30 +00:00
monitoring chore(monitoring): document health-check output 2026-05-04 16:34:27 -07:00
platform-service fix(platform-service): resolve 3 TS errors in /devops/info handler 2026-05-23 12:46:10 -07:00