I would block it. The schema is still valid, but the meaning of the response changed. The old 409 meant “the outcome is unknown, reconcile using this key.” The new one means “do not wait, this action failed.” The client behavior is the contract we care about, and in this case it can produce a second payment. We should not let green tests reassure us if those tests only assert the status code and JSON shape.

First, reconstruct the state machine. For a given key and request fingerprint, what happens if the first call completed, is pending, failed before submission, or completed at the provider while our database write is still pending? Which response tells a client to retry with the same key, poll, or stop? What happens if the same key is reused with a different amount? Write these as consumer-visible examples with exact codes, fields and retry rules. An API contract includes error semantics, not merely request and response types. AWS's service contract guidance calls out contract tests and versioning for independently deployed consumers.

For this change, I would add a test at the service boundary that holds the first provider call open, sends the duplicate request, and asserts the pending response and the final reconciled outcome. Then run the old client behavior against the new server, including the scenario where the client sees a timeout rather than a clean response. A consumer contract or recorded client simulation can catch the dangerous interpretation. Tests of only the new handler cannot. Do not make the agent's own new tests the sole judge of its patch, especially when it has changed a branch the old tests never exercised.

There is a release question even after the patch is fixed. Are all clients upgraded, including older mobile clients and partner integrations? If not, preserve the old semantics or expose a versioned behavior with a planned migration. A feature flag on the server is useful only if routing and rollback can identify affected clients, and a rollback cannot undo a payment already submitted twice. Instrument duplicate-key collisions, new-key resubmissions after pending responses, provider submission count and reconciliation time. Keep the idempotency ledger as the authority across deploys.

If the interviewer says the endpoint documentation never mentioned payment_pending, I would still investigate observed use before removing it. A de facto contract can exist in clients and SDKs even when documentation is incomplete. We can decide to deprecate it, but the decision needs an impact inventory and staged migration, not an agent silently changing the meaning in a “retry fix.”

To make future agent work safer, give it the consumer contract, examples of pending and unknown external effects, and a CI gate that is maintained outside the patch's own test edits. Ask its review report to state which externally visible behavior changed. An agent changes an API used by twelve repositories. In what order can it ship? deals with the order of a cross-repository API migration. This question is narrower and harder in another way: the shape did not change, but the action a real client takes did.