The customer API offers no idempotency key or request-status lookup. A record-creation call times out. What would you do?

Instruction: Use the stated legacy API limitation. Explain customer reconciliation ownership and what the operator sees when no reliable creation outcome can be established.

Context:

Work through a fictional timeout with a matching external record and concurrent operator activity. Decide what can be established, how the business request is resolved and how unresolved creation is operated.

Practice task

Use this fictional customer deployment case to decide what happens next. You do not need to write code; explain the evidence, propose the next operational steps and write a brief update that a customer operator could use.

Provider contract and business context

  • POST /service-visits creates a visit. It accepts no idempotency key and offers no request-status lookup.
  • Matching account, site, date and purpose does not enforce uniqueness. The provider permits records with identical values.
  • The integration's local_operation_id exists only in its own protected log. It was not sent to or saved by the provider.
  • A read-only search can return visits, but visibility is delayed and the provider gives no maximum delay. The search response does not include the creator or a request-correlation reference.
  • The customer operations lead can decide whether an existing visit meets the business request and owns unresolved work. No additional audit evidence has been obtained yet.

Fictional client trace

2026-10-04T16:00:00Z  local_operation_id=op-204
                       POST /service-visits
                       account_id=A17, site_id=S04
                       requested_date=2026-10-12, purpose=annual inspection
2026-10-04T16:00:01Z  client finished writing the request body
2026-10-04T16:00:06Z  response deadline expired; no response headers received
2026-10-04T16:00:09Z  read-only search returned the record below

External record and operator evidence

visit_id:       SV882
account_id:     A17
site_id:        S04
requested_date: 2026-10-12
purpose:        annual inspection
created_at:     2026-10-04T16:00:03Z

A customer operator says: “I also opened a visit for that account and date around the same time. I don't know whether my save completed.” Their action could have produced the matching record. They have not confirmed that it represents the same intended work as the integration request.

Explain what the trace establishes and what remains unknown. Propose how the customer can resolve the business request without misleading the operator about the original write. Include who owns the next decision, what information you would seek, how you would treat another creation attempt, and one change you would require before expanding unattended creation.

Updated

Example Answer

I'd keep the original write outcome unknown and stop automatic replacement attempts for this request. The client sent a body but received no response. The matching visit may be ours or the operator's, and delayed search visibility means another record could still appear. Its fields and creation time do not establish causation.

I'd bring the operations lead and system owner into the reconciliation. We'd check any available authoritative evidence and whether SV882 actually meets the intended business request. If the customer accepts that visit, I'd record that resolution separately from the unconfirmed outcome of op-204. I'd avoid deleting or creating records just to make our log look conclusive.

I'd leave the unresolved operation visible with an owner, the known evidence and the next decision. Before unattended creation expands, I'd require a supported duplicate-prevention or recovery contract. Without one, I'd keep this step supervised or choose a narrower deliverable.

Make it your own

Use a real provider contract only if you can explain it accurately. Name the customer owner, the business consequence of a duplicate and how an operator finds unresolved work. The supplied trace is fictional.

Why this works

It distinguishes an observed business record from proof of a specific write, and gives the customer an operational decision without fabricating certainty.

Modeled reasoning

What the evidence establishes: The client completed its local send step and failed to receive a response. A read-only search returned a visit with matching fields. Both the integration request and a concurrent operator action are plausible causes of that record.

What it does not establish: The trace does not prove that the provider accepted our request, that SV882 is our result, that our request failed, or that no duplicate exists. The local operation ID supplies no remote correlation. Waiting for another search can add evidence, but the stated visibility contract cannot prove that a missing record was never created.

A defensible next step: Keep replacement creation for op-204 paused while the customer operations lead and system owner reconcile it. Seek available authorized audit evidence and clarify whether the observed visit represents the intended work. If the customer accepts an existing visit as the business resolution, retain that decision and the record reference; do not relabel the original write as confirmed. Another defensible outcome is to keep the business request unresolved while evidence or an authorized operating decision is obtained.

Operator handling: Show the request, known record, uncertainty, owner and next action together. A manual retry or cleanup is a customer operating decision with real duplicate or deletion consequences, not a technical guarantee produced by approval. Review any later matching records before changing them.

Customer update: “The request timed out before we received a result. We can see a matching visit, but concurrent activity means we cannot yet link it to our request. We have paused another creation attempt and are checking with your operations lead whether that visit fulfils the intended work. We'll record that decision and keep the original uncertainty visible.”

Before expansion: Ask the provider owner for an enforced unique operation reference, documented idempotent creation or a supported status-and-recovery mechanism. Those are possible future contract changes; none can retroactively prove what happened in this trace. Test lost responses with customer operators and verify the resolution procedure before approving unattended creation.

Interviewer follow-up

The operations lead wants to use SV882 now and says a possible duplicate can be reviewed later. Is that acceptable?

I'd clarify that SV882 fulfils the intended work, who owns later duplicate review and what harm another visit could cause. If that customer owner has authority and accepts the remaining operating risk, using the existing visit may be a defensible business resolution. I'd record the decision without claiming op-204 succeeded or that duplicates are impossible. If duplicate harm cannot be managed, I'd recommend keeping the affected work supervised.

Assessment criteria

Strong: Separates known facts from attribution and completeness, avoids an unsafe automatic replacement, names the customer decision owner and distinguishes business resolution from the original write outcome. Several resolution paths are valid when their evidence, authority and consequences are explicit.

Adequate: Recognizes an unknown write, pauses automatic retries and asks the system owner to investigate. Gives the operator a usable next step, but may need prompting about the matching record or concurrent activity.

Weak: Calls the matching record proof of success, treats a missing response as proof of failure, promises that manual approval prevents duplication, or deletes a plausible legitimate record without establishing its role.

Tempting weak answer

“SV882 has the same fields and was created during our request, so I would mark op-204 successful and close the issue.”

Why it fails: The concurrent operator action could have produced SV882. Matching values and timing cannot link it to our request, and delayed visibility leaves possible duplicate creation unresolved. The business may choose to use the record, but the audit statement must remain accurate.

References

Related Questions