Frequently Asked Questions

How does Reccy handle network requests?

Reccy records network responses (XHR, Fetch, WebSocket) during the initial session. When replayed, these responses are automatically stubbed, ensuring tests are:

• Fast — No waiting for real API responses
• Deterministic — Same data every time
• Side-effect free — No actual backend calls

Different users or data variants get their original responses during replay, enabling coverage across user types and states.

What is and isn’t mocked?

Mocked by Reccy:

• XHR (XMLHttpRequest) requests
• Fetch API requests
• WebSocket connections
• Local storage, session storage, cookies

NOT mocked:

• Static assets (CSS, JS, images) loaded via HTML tags
• Assets with absolute URLs in HTML

Use relative URLs for static assets to ensure they load correctly across test environments.

How are sessions selected for testing?

Reccy analyzes code coverage per session and selects a minimal set that covers all distinct code paths, components, and routes. See Session Selection for details.

Will localhost sessions break my tests?

No. Reccy filters out broken sessions and takes baseline screenshots at replay time, not record time. Sessions from incomplete features produce identical screenshots on both commits, showing no diff.

---

CI Setup

How does URL rewriting work?

Reccy swaps the origin URL when simulating:

Recorded:  https://production.com/path?query=value
Simulated: https://preview-abc.vercel.app/path?query=value

This applies to page navigation and API requests. Static assets with absolute URLs are not rewritten.

Which branches need Reccy workflows?

Reccy must run on:

• Main branch — For baseline screenshots
• PR branches — For comparison screenshots

Both deployments should have identical configuration (environment variables, feature flags) to avoid false diffs.

Can I record in production and test on preview URLs?

Yes, but sessions may fail if environments differ significantly. Ensure:

• Same authentication configuration
• Same URL routing patterns
• Same environment variables

CLI vs GitHub Actions limitations

The CLI works for most cases but has some limitations compared to the GitHub Action:

• Can’t regenerate baselines if Reccy’s snapshotting logic updates
• No automatic retry if initial connection fails
• Can’t lazily trigger base commit runs (useful for monorepos)

---

Recorder Setup

Why must the recorder be the first script?

Libraries may snapshot references to window.fetch or XMLHttpRequest early in the page lifecycle. If Reccy loads after them, it can’t intercept and record those requests. The recorder must be first to capture all network activity.

Sessions aren’t appearing

Check these common causes:

1. Script order — Reccy snippet must be before all other scripts
2. Async/defer — Remove these attributes from the Reccy script
3. CSP blocking — Add Reccy domains to your Content Security Policy
4. Wrong token — Verify recording token matches your project

CSP exceptions needed

script-src: https://app.reccyai.com
connect-src: https://app.reccyai.com

---

Troubleshooting

False positive diffs

If you see diffs that aren’t real changes:

1. Flag as unexpected — Click the diff and select “Flag as Unexpected” to report
2. Ignore elements — Configure element-level ignore rules for known dynamic content (timestamps, ads, etc.)
3. Check environment consistency — Ensure main and PR deployments use identical configuration

Authentication issues

If authenticated sessions fail to replay:

• Verify auth tokens are recorded (check session details in dashboard)
• Ensure the test environment accepts recorded auth tokens
• Check for IP-based restrictions that might block CI runners

Simulation failures

Debug locally first:

npx @reccyai/cli simulate \
  --apiToken="<<TOKEN>>" \
  --sessionId="<<ID>>" \
  --appUrl="http://localhost:3000" \
  --debugger \
  --devTools

The --debugger flag lets you step through events one at a time.

---

Support

Need help? Contact support@reccyai.com.