Debugging guides
Chrome DevTools Local Overrides: useful mocks, limited saved setup
The API returns "canApprove": "false". The button is enabled anyway. Before touching the backend, change the response locally to "canApprove": false and reload. If the button now disables, you have a useful lead about the type handling.
Try the response change with Chrome DevTools Local Overrides before adding another tool.
Then check what survives a reload. The overridden response can survive; the selected organisation and unsaved draft are a separate question. The approval screen in this guide is an invented example.
Start with a small override
DevTools can store local overrides for supported resource content and HTTP response headers. The overridden version is used across reloads while the feature is active. Chrome documents the setup under Sources → Overrides and the actions available from the Network panel. 1
In a test application, locate the API request in Network, choose the response-content override action and grant DevTools access to a dedicated local folder when prompted. Change only the field whose type is in question:
{
"documentId": "approval-example",
"canApprove": false
}Reload and confirm the modified body in Network before inspecting the button. Then test boolean true, a missing field and, if permitted by the API contract, null. Keep the rest of the response unchanged so each check isolates the interpretation of canApprove.
A locally disabled button is not proof that the server enforces approval permissions. Keep that authorisation question separate from the rendering check.
Do not confuse Overrides with an Elements edit
Changing a node or style in the Elements panel can be a useful live experiment, but it is not the same as saving an overridden response. Chrome lists limitations for Local Overrides, including that changes to the DOM tree in Elements are not saved by that mechanism. 1
For the approval example, deleting the button from the DOM proves almost nothing about the application fix. Changing the response tests how the existing code interprets the input. Changing the code and executing it again tests a candidate fix.
Note whether you changed the DOM, the response or the application code. A screenshot of a disabled button does not distinguish them.
Importing a HAR does not reopen the application
Chrome’s Network panel can export a HAR and import one for analysis. Importing it displays recorded requests; it is not a command to launch an application with all of those responses, forms and interactions restored. 2
To execute browser code against recorded HTTP responses, use a replay mechanism such as Playwright’s routeFromHAR() and supply the needed test or setup. HAR matching has its own constraints, including URL and method identity. 3
Repeating one XHR is another operation again: it sends a request. It does not re-enter the draft or execute the UI actions that originally produced it.
For a prepared Playwright workflow, see the HAR guide. This article does not describe importing arbitrary HAR files into StatePort.
Record which experiment changed the button
A useful note for the approval example might be:
Observed: string "false" enables the approval button.
Experiment: override only canApprove with boolean false.
Result to record: button state and relevant console output.
Candidate fix: validate or interpret the API field explicitly.
Separate check: server rejects an unauthorised approval request.Fill in the observed result, response status and request identity before sharing the note. State whether the override was active so a reviewer can distinguish it from a live API check.
Disable the override for the live integration check and verify the response came from the test service. Keep the reviewed fixture separately if it becomes a regression test; label it with the hypothesis, not simply latest-response.json.
When the draft is harder to restore than the response
Suppose the approval button only appears after changing organisations, opening a particular document and editing a draft. The override gives you the API condition, but you still rebuild that UI setup after each refresh or handoff.
At that point, evaluate a StatePort capture. Reproduce the supported case in its managed browser, review the retained material and save a State Card. Reopen it against Local app to work with changed frontend code and matching retained dependencies. 4, 5
Check that the document, draft and permission-dependent control are actually restored. If the important state is unsupported, a partial capture is not a substitute for the missing setup. A test fixture or an approved backend seed may be more suitable.
The Card does not contain the entire server or grant the recipient the original user’s permissions. Authentication and protected local material have separate rules. 5
Review the data before handing it over
Chrome’s sanitised HAR export omits headers such as Cookie, Set-Cookie and Authorization. Review bodies, query values and business identifiers separately before sharing the archive; the sanitised label is not a clearance for arbitrary application data. 2
The same caution applies to an override file or a State Card. Use synthetic values where possible, keep credentials out of tickets and do not upload an internal payload merely to illustrate a public bug.
For one field and a short path to the screen, Local Overrides may be all you need. For a repeatable supported case that another developer should open on changed code, compare StatePort’s capture workflow with the setup you would otherwise maintain. The Requestly guide covers the middle ground of reusable interception rules and recorded mocks.
Sources
Written by StatePort. Documentation checked on 13 October 2026. The approval example is invented and no browser-compatibility benchmark is asserted.