Make the changed feature visible
Give Pie’s test account the flag values your pull request expects, so the changed feature shows up on each run while it stays off for everyone else. If the flag resolves to the control value for that account, the feature stays hidden and nothing fails, so the run never tests your change.
Before you start
- Use a feature flag provider that can evaluate a cohort for Pie’s test identity.
- Create the test identity from Prepare identity, access, and test data.
- Publish the preview deployment manifest from Build a complete preview environment.
Create a test cohort
Define the cohort on an attribute your flag provider can evaluate for Pie’s test identity, such as a stable tenant, an account list, or a trusted test attribute:
{
"tenant": "pie-e2e",
"emailDomain": "example.test",
"testAutomation": true
}Target the cohort, not everyone. Don’t turn the feature on globally, and don’t rely on someone changing a flag by hand before each run.
Record the values in the preview manifest
Put the expected values next to the deployed revisions, so the manifest says what Pie should see:
{
"flags": {
"refund-workflow": true,
"new-order-details": "treatment"
}
}Apply these values to the test cohort before the deployment reports ready: true.
Verify what the test identity resolves
Check the value for the signed-in test user in one of these:
- An authenticated diagnostics page
- A non-secret readiness response
- The flag provider’s evaluation log
Confirm the resolved value, not only the global default. Targeting rules can override it.
For a per-PR override, scope the value to the preview identifier and the Pie test tenant. Remove it when the PR closes, and use a TTL in case the close hook fails.
What you’ll see
- Pie signs in with the intended test identity.
- The resolved values match the preview manifest.
- The target route shows the changed feature from a clean session.
- Disabling the flag in a disposable preview hides the feature.
- Restoring the value makes the feature available again without manual session repair.
Troubleshooting
- If the provider log shows the default value, the client evaluated the flag before the user context was set, so the run saw the anonymous default. Bootstrap the SDK after sign-in, or block the route until the context resolves.
- If the frontend shows the feature but the API rejects the request, the backend evaluates its own flag. Apply the same cohort on both sides and record both values in the manifest.
- If the feature appears for a developer but not for Pie, a cached session, a sticky bucketing key, or a local override is holding an older value. Start from a clean session and confirm the cohort attribute on the test identity.
If the value is right but the feature is missing, compare the frontend and backend SHAs in your deployment manifest.
Still blocked? Contact support@pie.inc.