REA browser analysis: what happens after Export?

01. Start an isolated browser session

Open your local application in a separate debugging profile. This makes the chosen page and test data clear. Replace the final URL with your own local app. On Windows or Linux, use the corresponding Chrome executable.

The debugging endpoint is the browser control connection; it is different from your application URL. Use the literal loopback address and the target ID returned by REA.

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/rea-export-profile \
  http://127.0.0.1:3000

02. Select the exact page

List the targets, locate your application URL and copy its target ID. Inspect that page before starting the experiment. If the tab reloads or is replaced, list targets again rather than reusing an old ID.

npx -y [email protected] list-browser-targets http://127.0.0.1:9222 --json
npx -y [email protected] inspect-web-page http://127.0.0.1:9222 TARGET_ID --observation-ms 1000 --json

03. Record a baseline, then one export

First record a short idle window so background polling is visible. Then start a second observation and click Export yourself while the window is open. REA’s passive observer does not click the button for you.

Keep the input small and recognizable, such as two rows with a unique test label. Note whether the app shows a spinner, downloads a file or reports an error. Compare the two captures rather than assuming every new request belongs to Export.

npx -y [email protected] observe-web-session http://127.0.0.1:9222 TARGET_ID --observation-ms 10000 --json > export-capture.json

• Does a request begin after the action?
• What are its method, URL and reported status?
• Can an initiator or loaded script connect it to the button?
• Was the downloaded file actually created, and does it contain the test rows?

04. No request? Inspect the client-side path

Some exports build a Blob in JavaScript and download it without a server request. An empty request list is therefore a useful clue, not proof that the capture failed. Inspect the loaded scripts and search the relevant feature for Blob, createObjectURL and the download attribute.

The bundle analysis reports static candidates. A string resembling an endpoint is not proof it was called. Keep request observations and source findings in separate columns.

npx -y [email protected] analyze-web-bundle http://127.0.0.1:9222 TARGET_ID --json

Using the selected page and this export capture, explain whether Export requests a server-generated file or builds the file in the browser. Connect the observed activity to the relevant loaded code. Show missing evidence. Do not infer response contents from metadata alone.

05. Repeat with an awkward input

Export a row containing a comma, quotation mark and line break. Open the resulting file with a parser for that format, not only a text editor. A download completing successfully does not prove the file is correctly encoded.

Deliver the action timeline, selected request or client-side function, and the file checks. This is a reproducible workflow for your own target; this article does not contain a captured session from a third-party service.