fix(api,dashboard): dev-workspace build compat + fail-closed feature flags#712
Open
lilongen wants to merge 3 commits into
Open
fix(api,dashboard): dev-workspace build compat + fail-closed feature flags#712lilongen wants to merge 3 commits into
lilongen wants to merge 3 commits into
Conversation
typeorm 0.3.29 widened the DISTINCT-pagination trigger to include .limit(), crashing quoted-orderBy lifecycle crons; pin to the last good 0.3.28. node-forge is used directly, so declare its types as a direct devDependency. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…pment `nx serve api` triggers the base build, which crashes in @nx/webpack's GeneratePackageJsonPlugin in this workspace and fails type-checking on a pre-existing @opentelemetry/otlp-exporter-base version skew (a type-only mismatch in tracing.ts; the exporters work at runtime). Drop both plugins only when NODE_ENV=development so the API builds/serves locally; production keeps the pruned deploy package.json and full type-checking. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ss envs When PostHog isn't configured, @RequireFlagsEnabled routes default to false (e.g. POST /regions, GET /runners return 404) and the dashboard's gated UI (Create Sandbox, etc.) goes blank. Add an optional bootstrapFlags map the provider/wrapper consult ONLY when PostHog has no apiKey AND NODE_ENV is not production — a prod deploy without a key still fails closed (gated routes stay hidden), enforced at both the injection site and inside the provider as defense-in-depth. Covered by openfeature-posthog.provider.spec.ts. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
📝 WalkthroughWalkthroughThis PR enables PostHog feature flags to function in local development when PostHog is not configured, while strictly failing closed in production. Bootstrap flags are conditionally injected in the API module and consumed by both backend provider evaluation and the frontend PostHog wrapper with environment-gated logic. ChangesBootstrap flags for local development PostHog integration
🎯 3 (Moderate) | ⏱️ ~22 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
lile seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
Contributor
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Enable local development to render/serve feature-flag-gated UI and API routes when PostHog isn’t configured, while preserving fail-closed behavior in production.
Changes:
- Add local-dev bootstrap feature flag defaults for the dashboard when PostHog config is absent.
- Add bootstrap flag support to the API OpenFeature PostHog provider + tests, and wire bootstrap flags from
app.module.tsoutside production. - Adjust API webpack config to skip package-json generation and TS type-checking plugins in local development; update a couple of dependencies.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| apps/package.json | Pins typeorm version and adds @types/node-forge. |
| apps/dashboard/src/components/PostHogProviderWrapper.tsx | Adds local-dev PostHogProvider bootstrap to keep flag-gated UI rendering when unconfigured. |
| apps/api/webpack.config.js | Skips GeneratePackageJsonPlugin and ForkTsCheckerWebpackPlugin in development to unblock local serve. |
| apps/api/src/common/providers/openfeature-posthog.provider.ts | Adds local-dev bootstrap flags while keeping production fail-closed behavior. |
| apps/api/src/common/providers/openfeature-posthog.provider.spec.ts | Adds tests ensuring bootstrap flags are ignored in production. |
| apps/api/src/app.module.ts | Injects bootstrap flags outside production when PostHog API key is missing. |
Comment on lines
+79
to
+92
| <PostHogProvider | ||
| apiKey="phc_local_dev_no_op" | ||
| options={{ | ||
| // api_host is required by posthog-js but never used because | ||
| // capturing is opted out and flags are bootstrapped below. | ||
| api_host: 'https://localhost.invalid', | ||
| bootstrap: { featureFlags: LOCAL_DEV_FEATURE_FLAG_DEFAULTS }, | ||
| advanced_disable_feature_flags: true, // skip /decide network call | ||
| autocapture: false, | ||
| capture_pageview: false, | ||
| capture_pageleave: false, | ||
| opt_out_capturing_by_default: true, | ||
| disable_session_recording: true, | ||
| loaded: (posthog) => posthog.opt_out_capturing(), |
Comment on lines
+224
to
+233
| ...(process.env.NODE_ENV !== 'production' && { | ||
| bootstrapFlags: { | ||
| organization_infrastructure: true, | ||
| organization_experiments: true, | ||
| dashboard_playground: true, | ||
| dashboard_webhooks: true, | ||
| 'dashboard_create-sandbox': true, | ||
| sandbox_spending: true, | ||
| }, | ||
| }), |
Comment on lines
+47
to
+48
| this.bootstrapFlags = | ||
| process.env.NODE_ENV === 'production' ? {} : (config.bootstrapFlags ?? {}) |
Comment on lines
+49
to
+54
| if (process.env.NODE_ENV === 'development') { | ||
| const devSkipPlugins = new Set(['GeneratePackageJsonPlugin', 'ForkTsCheckerWebpackPlugin']) | ||
| config.plugins = (config.plugins || []).filter( | ||
| (plugin) => !devSkipPlugins.has(plugin?.constructor?.name), | ||
| ) | ||
| } |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/package.json`:
- Line 253: The package.json entry for `@types/node-forge` (^1.3.14) alongside
node-forge (^1.4.0) is acceptable but may produce minor type drift; leave the
dependency versions as-is and add a short comment or repository note to monitor
for type mismatches, or add a package-lock/yarn.lock update step to ensure
consistent installs; reference the dependency names "`@types/node-forge`" and
"node-forge" when making the note or adding an actionable TODO so reviewers can
easily find and revisit it later.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 2f94f9eb-db61-4d3a-ad25-3d6a2752b3e2
📒 Files selected for processing (6)
apps/api/src/app.module.tsapps/api/src/common/providers/openfeature-posthog.provider.spec.tsapps/api/src/common/providers/openfeature-posthog.provider.tsapps/api/webpack.config.jsapps/dashboard/src/components/PostHogProviderWrapper.tsxapps/package.json
| "@types/jest": "30.0.0", | ||
| "@types/multer": "^1.4.12", | ||
| "@types/node": "^22.13.4", | ||
| "@types/node-forge": "^1.3.14", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Are @types/node-forgeversion 1.3.14 types compatible with node-forge version 1.4.0, and does a@types/node-forge version 1.4.x exist?
💡 Result:
As of June 10, 2026, there is no version 1.4.x of @types/node-forge; the latest available version is 1.3.14 [1][2][3]. Regarding compatibility, @types/node-forge version 1.3.14 is generally used with node-forge version 1.4.0, though users may encounter minor type-related incompatibilities depending on their specific implementation. For example, some development teams have found it necessary to cast certain objects or handle widened types (such as pki.PrivateKey) explicitly when upgrading to node-forge 1.4.0 while using the 1.3.14 types [4][5].
Citations:
- 1: https://www.npmjs.com/package/@types/node-forge
- 2: https://www.npmjs.com/package/@types/node-forge?activeTab=versions
- 3: https://security.snyk.io/package/npm/%40types%2Fnode-forge
- 4: microsoft/rushstack@1504c2c
- 5: Bump node-forge to 1.4.0 & @types/node-forge to address CVEs microsoft/rushstack#5738
@types/node-forge 1.3.14 vs node-forge 1.4.0: acceptable but keep an eye on minor type drift
@types/node-forge has no 1.4.x release line—the latest version is 1.3.14. So using ^1.3.14 alongside node-forge ^1.4.0 is the expected/latest pairing; minor type mismatches may still happen depending on usage, but this is not a versioning bug in the dependency declaration itself.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/package.json` at line 253, The package.json entry for `@types/node-forge`
(^1.3.14) alongside node-forge (^1.4.0) is acceptable but may produce minor type
drift; leave the dependency versions as-is and add a short comment or repository
note to monitor for type mismatches, or add a package-lock/yarn.lock update step
to ensure consistent installs; reference the dependency names
"`@types/node-forge`" and "node-forge" when making the note or adding an
actionable TODO so reviewers can easily find and revisit it later.
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
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.
What
Three independent, production-safe fixes extracted from the infra-local work so they can be reviewed on their own merits:
typeormto0.3.28(0.3.29 widened the DISTINCT +.limit()pagination trigger and crashes quoted-orderBy lifecycle crons) and declare@types/node-forge(imported directly inuser.service.ts).nx serve apicrashes in@nx/webpack's GeneratePackageJsonPlugin and fails type-check on a pre-existing OTLP exporter version skew. Skip both plugins only underNODE_ENV=development; production keeps the pruned deploy package.json and full type-checking.@RequireFlagsEnabledroutes 404 and the dashboard's gated UI goes blank. Add abootstrapFlagsmap consulted ONLY when PostHog has no apiKey ANDNODE_ENV !== 'production'. A keyless production deploy still fails closed (gated routes stay hidden), enforced at the injection site and inside the provider; covered by a new spec.Why
These are not infra-local changes — they make the api/dashboard build and behave correctly in any environment without external SaaS, and (1)/(3) are genuine correctness/security improvements that benefit production.
Prod impact
None in the default path: (2) is dev-only, (3) fails closed in prod, (1) is a dependency convergence. No local-only logic ships in a prod code path.
Test
openfeature-posthog.provider.spec.tsguards the prod fail-closed gate (dev → bootstrap honored, prod → forced empty).nx build api --configuration=productionpasses; the dashboard renders its gated UI against a PostHog-less local stack.Files
apps/package.jsonapps/api/webpack.config.jsapps/api/src/app.module.tsapps/api/src/common/providers/openfeature-posthog.provider.tsapps/api/src/common/providers/openfeature-posthog.provider.spec.tsapps/dashboard/src/components/PostHogProviderWrapper.tsx🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Tests
Chores