Debug a browser export with a one-action network trace

A browser job opens a reporting page, changes the month, clicks Export, and receives a file. The job looks successful. The file contains last month's records.

That is a useful debugging scenario because clicking the same button again does not explain which month the application actually requested. The page label, the request parameters, and the downloaded artifact are separate pieces of evidence.

This tutorial proposes a small investigation procedure for that situation. It uses BrowserAct's documented request inspection commands. The export scenario is illustrative; it is not a report of testing a particular billing portal.

Start with one question

Before capturing traffic, write down the uncertainty you want to resolve. For example: "Did changing the month affect the request that generated this export?"

That question sets a much better boundary than "collect all network traffic." It tells you which action to perform, which requests deserve attention, and what would count as an answer.

Also record the expected account, date range, and record type outside the capture. A response cannot prove that a workflow selected the correct organization if you never wrote down the intended organization.

Isolate one interaction

Use your own named session in a browser that you are authorized to operate. Navigate to the relevant page and inspect its current state:

browser-act --session export-debug state

Read the current element list and locate the month selector or filter by its meaning. The numerical indices belong to that particular state snapshot. Do not copy an index from a previous run and assume it still identifies the same control.

Once the page is ready, clear earlier captured traffic:

browser-act --session export-debug network requests --clear

Then perform exactly one meaningful action, such as applying the date filter. Inspect the current page again before deciding which control to use next. Mixing filter changes, pagination, and repeated export clicks into one experiment makes causal interpretation harder.

Find the response that matters

Start with likely data calls:

browser-act --session export-debug network requests --type xhr,fetch

Read the captured request list. Choose a request because its URL, timing, and purpose match the action you just performed. The first successful request might be analytics or application configuration rather than your report.

After finding a candidate, use the request ID returned by the current capture:

browser-act --session export-debug network request <request_id>

Inspect its method, parameters, and response together. A date might be supplied in a JSON body rather than the URL. Pagination might be represented by a cursor rather than a page number. Treat those as observations from this application, not conventions to assume everywhere.

Separate three outcomes

A useful investigation distinguishes these cases:

1. The request contains the wrong scope. Return to the filter or account-selection step. Retrying the export repeats the same mistake.
2. The request contains the intended scope, but the response is incomplete or unexpected. Investigate the application's response and any subsequent requests before changing selectors.
3. The response appears correct, but the saved file differs. Follow the export and download sequence. A table request and an export-generation request may serve different purposes.

HTTP 200 only describes the transport-level response. It does not establish that all pages were included, the requested account was selected, or the file is an invoice rather than a summary report.

Leave a small evidence note

You rarely need to paste an entire capture into a ticket. A compact note can carry the reasoning:

Expected: organization A, September, invoice documents
Action observed: applied September filter once
Request observed: date bounds matched September
Response observed: 25 rows and a continuation cursor
Unresolved: whether export includes later pages
Next experiment: inspect the export-generation request

These are fictional observations, not actual BrowserAct output or a product schema. Their purpose is to show what a useful handoff contains: expectation, observation, uncertainty, and one next action.

Keep session cookies, authorization headers, private records, and signed download URLs out of the shared note. Network inspection can expose more information than a screenshot of the table.

Decide what to automate after the investigation

Finding a structured response does not establish a stable public API contract. It might rely on a cookie, a CSRF token, prior browser actions, or an expiring URL. Keep the existing browser flow until you understand that dependency.

The practical result of this procedure is a narrower next decision: fix selection, investigate pagination, or inspect file generation. That is enough progress for one debugging pass. Automating a guessed endpoint before resolving those questions only moves the uncertainty into code.

For the broader request-inspection workflow, see our BrowserAct network inspection guide.