A completed request can still contain a rejection

A browser can receive an HTTP response successfully while the application at the other end rejects the requested operation. If the interface treats a fulfilled Fetch promise as business success, it can tell a customer that staff received a request that was never stored.

This fictional investigation follows a specification enquiry. It examines an explicit rejection, not an uncertain network timeout. The receiver's documented response and isolated records allow the team to establish what happened before changing the message or inviting another submission.

Start with the contradictory evidence

The customer submits enquiry attempt A-71 without the required finish selection. The interface immediately displays “Your enquiry has been received” and clears the fields. The staff queue has no corresponding enquiry.

The captured response is HTTP 422 with the fixture's documented body: stored: false and a field error identifying the missing finish. The receiving log confirms that validation rejected A-71 before creating an enquiry record. The application has not lost a stored record; it has shown an acceptance message for a rejected operation.

The old client code awaits fetch, then displays success. Its error message lives only in catch. Because the server supplied an ordinary HTTP response, execution takes the fulfilled path even though the response status indicates rejection.

Separate transport completion from application acceptance

The Fetch standard distinguishes a network error from receiving a response object. Receiving an HTTP error status does not by itself take the same path as a rejected Fetch promise. The application must examine its response contract.

In this fixture, accepted creation requires HTTP 201 and a valid stored receipt containing the new enquiry reference. HTTP 422 plus the defined field-error body means the operation was rejected without storage. Other statuses and malformed bodies have separately defined handling; they are not silently coerced into either accepted or safely absent.

The team writes these conditions beside the UI states. This makes the repair reviewable without relying on the colour of a banner or the name of a JavaScript branch.

Correct the transition before changing the words

The repaired client reads the status and validates the relevant response shape. For the documented 422 result, it preserves the customer's entered details, explains the finish error next to the field and gives the customer a way to correct it. It does not display an enquiry reference or clear the form.

For the successful 201 receipt, it displays the actual new reference and then follows the agreed form-reset behaviour. A generic 2xx response without the expected receipt does not establish the stronger business claim on its own.

The receiving validation remains authoritative. The client may help users complete the field, but removing a browser check or sending a crafted request must not create an invalid enquiry. The repair changes the interpretation of the response; it does not relax the business requirement to make the success path easier.

Complete a deliberately corrected submission

The isolated demonstration first repeats A-71's missing-finish case. The receiver again rejects it, the UI shows the specific field correction, and no enquiry appears in the staff queue. The supplied non-sensitive fixture details remain on screen.

The reviewer then chooses the approved finish and deliberately submits a new attempt A-72. The receiver returns HTTP 201 with stored: true and reference E-72. The interface displays E-72, and the staff view shows the correct finish and specification reference for that enquiry.

The later request is a considered correction after verified rejection. It is not an automatic replay of an operation whose receipt is unknown.

Keep the uncertain cases separate

A network failure can leave the browser without a usable response even if a receiver performed some work. A server error can likewise require investigation under the application's actual contract. The team therefore retains an uncertain-result path that asks for receipt reconciliation before resending when storage is not known.

A simulated malformed success body must not produce a fabricated reference. A valid independent enquiry E-70 remains unchanged. Direct receiver checks continue to refuse a missing finish even when the client-side aid is bypassed. These controls stop a narrow UI correction from becoming a broader acceptance or duplication defect.

Make the acceptance record useful to support

Record the original attempt, explicit rejection, faulty branch, repaired conditions and the separate E-72 receiving result. Include the field that remained required and the cases that still demand investigation. Support staff can then distinguish “correct this rejected request” from “we need to find out whether the request arrived”.

For integration work, ask what evidence permits each customer-facing statement. An HTTP response, a successful transport operation and a stored business record are related events, but they are not interchangeable facts.