Make the Changed Feature Visible

A healthy preview and a working login still leave one way for a run to go quiet. If the flag behind your change resolves to the control value for Pie’s test identity, the feature stays hidden and nothing fails. Pie tests what it can see. Give the test identity the same flag values your pull request expects and the change shows up on every run, without turning it on for everyone.

Step 1: 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 the whole population. Do not enable the feature globally, and do not depend on an engineer changing an admin setting before every run.

Step 2: Record the Values in the Preview Manifest

Put the expected values alongside the deployed revisions so the manifest is the single answer to “what should Pie see”:

{
  "flags": {
    "refund-workflow": true,
    "new-order-details": "treatment"
  }
}

Apply these values to the test cohort before the deployment reports ready: true.

Step 3: Verify What the Test Identity Resolves

Check the value for the signed-in test user through one of these paths:

• 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.

Confirm the Feature Appears

1. Pie signs in with the intended test identity.
2. The resolved values match the preview manifest.
3. The target route shows the changed feature from a clean session.
4. Disabling the flag in a disposable preview hides the feature.
5. Restoring the value makes the feature available again without manual session repair.

Troubleshooting

• 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.
• 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.
• 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 correct but the feature is absent, compare the frontend and backend SHAs in your deployment manifest.

When the feature is visible but Pie still meets a challenge or a 403, the next blocker is network access.

Need Help?

• Support: support@pie.inc