A city FDM object-create POST times out; the client cannot tell whether the firewall object was created. Which approach is the robust default for that non-idempotent write?
Select an answer to reveal the explanation.
Short Explanation
A create that went silent may already be filed at city hall. Blindly mailing a second form can invent a duplicate. Mark it uncertain—confirm, key it, or escalate—don't always retry POST.
Full Explanation
A non-idempotent FDM object-create POST that times out leaves an uncertain outcome: the firewall object may or may not exist. The robust default is to treat the result as unknown—use an idempotency key on creates when the API supports it, follow up with a GET or inventory query if available, or fail the unit for an operator—rather than blindly POSTing again and risking duplicates.
Always POSTing again immediately because “timeout means nothing was stored” assumes knowledge you do not have and can create duplicate objects. Treating POST like GET and retrying forever without duplicate checks applies idempotent-read logic to a create. Disabling all timeouts so creates hang until reboot replaces uncertainty with worker pin and still never clarifies whether the object landed.
Exam caveat: safe automatic retry of POST requires explicit idempotency support or a confirmed “not created” probe; without that, escalate. Operational check: after an FDM create timeout, query by name/UID or correlation id before any second POST; if the API offers idempotency keys, send the same key on intentional retries and document the operator fail path in the runbook. Duplicate network objects from blind POST retries create cleanup toil on FDM and can break later automation that assumes unique names. Build the create path so timeout handling branches to “reconcile or escalate” rather than “always rewrite,” and rehearse that path in a lab before production change windows.