Activity, errors and uncertain outcomes

Review Activity & requests#

Open Actions → Activity & requests as an owner or admin. The page shows the latest 60 runs, including labeled tests. Expand a run to inspect its name, time, operation mode, inputs, mapped result, error code and reference. Select Refresh for the latest state.

Built-in requests additionally show an open or resolved state and the verified contact email. A run’s execution status and a request’s team-handling state are different: an Action can successfully record a request that your team has not resolved yet.

The latest-runs view is a working activity list rather than a complete permanent ledger. Correlate an incident promptly and preserve any longer-lived business evidence in the destination's controlled records.

Interpret the execution status#

Read the operation mode alongside the status. An unknown external write requires a destination check even when its safe error looks similar to a failed read. A missing reply is not proof that nothing changed.

What the run reference guarantees#

Reesponder makes a one-time local claim of each pending run. A custom HTTP request includes the reference as its Idempotency-Key header; a POST includes the same value as idempotencyKey. Your endpoint must atomically store the key and the business result, then return that result for a replay.

This is not a distributed transaction across both systems. Your server might commit a change before the response is lost. Pausing, deleting or cancelling an Action cannot roll back a completed mutation. Creating a new proposal normally creates a new run reference, so remote deduplication of the old reference does not make a new operation automatically safe.

Store the outcome under the same key in the same consistency boundary as the mutation where your system supports it. A check-then-write sequence without locking or uniqueness can still race two simultaneous requests.

Recover from an unknown write#

For an external write, provider errors are recorded as unknown rather than automatically repeated. Find the reference in your endpoint’s idempotency ledger or logs. If the destination recorded the operation, confirm its actual result with the customer. If it definitely did not, repair the cause and decide whether a fresh, explicitly confirmed operation is appropriate.

If you cannot establish the outcome, contact the system owner and keep the customer informed. The widget’s Check status control refreshes Reesponder’s recorded state; it does not rerun the mutation or query an arbitrary provider status endpoint. Maintenance marks stale running executions unknown after 15 minutes.

Configuration edits do not reconcile a destination. Saving a new endpoint can fix future calls while leaving the previous write uncertain. Keep the original reference and investigation separate from the new configuration test.

Common error codes#

Fix the cause, save and retest the new configuration before enabling it. Share the run reference with support, not the bearer token or complete customer record.

execution_failed is a bounded fallback when no more specific safe provider code is available. Investigate with the run reference and destination owner instead of exposing a raw server exception to the customer.

Worked example: the request committed, the reply was lost#

Your delivery-change handler records request REQ-1042 under the supplied idempotency key, then its connection closes before Reesponder receives the reply. Activity shows an unknown external write. The customer has no confirmed result in chat, but the destination already has a durable request.

Find the original run reference in the handler's ledger. Confirm the recorded request and actual processing state. Tell the customer that their request was received if the evidence supports that statement, and explain any remaining review. Do not say the delivery changed merely because a request exists.

If the destination can prove that no mutation or queued request occurred, fix the cause and decide whether to prepare a new explicitly confirmed operation. If the evidence remains inconclusive, keep the outcome uncertain and involve the system owner. Repeated new proposals create new references and can create duplicate work.

Pressing Check status refreshes Reesponder's stored card. It does not query an arbitrary destination reconciliation endpoint or replay the write. Provider reconciliation is an operational step that your endpoint and team must support.

Prove the recovery behavior with controlled fixtures#

Test two identical requests with one key and concurrent duplicates in your adapter. They should create one business operation and return its recorded outcome. Simulate a lost reply after commit and verify staff can locate the accepted result by reference.

Also test an expired pending proposal and a paused definition. These should not be confused with an external write already running. Keep run reference, time, mode and safe error in diagnostics; do not include credentials, verification codes or full provider records.

Use a consistent uncertain-outcome runbook#

First, identify the exact run, Action, website and operation mode. Record its time and safe error. Avoid asking the customer to submit again while this first operation may have changed the destination. If necessary, pause future availability while your team investigates, understanding that a pause cannot roll back a request already sent.

Second, look up the run reference in the destination's idempotency record or protected logs. Distinguish an accepted and completed operation, an accepted but queued operation, a proven rejection before mutation and an unresolved outcome. Each supports a different customer statement.

Third, choose a recovery consistent with that evidence. A completed operation needs communication, not duplication. A queued request needs monitoring under its original reference. A proven non-operation can be repaired and reconsidered as a new confirmed request. An unresolved case needs the system owner rather than a blind retry.

Finally, record what caused the uncertainty and how it was established. Improve timeouts, durable results or correlation where appropriate, then retest the adapter and saved Action. Retain the operational record under your own controlled policy; expiring conversation history is not the destination's idempotency ledger.

Keep business state separate from transport state#

A provider's 2xx JSON response establishes that the request returned an accepted transport result. The mapped status must still say what happened in business terms. “Request received” may be correct while a staff member has not reviewed it. “No eligible appointment” may be a normal authorized answer rather than an infrastructure failure.

A non-2xx response is a provider rejection at the transport contract. For an external write it still enters uncertain-outcome handling because the destination might have made a change before returning an error. Design your handler so staff can inspect the durable outcome, not infer it solely from HTTP status.

A failed read can generally be investigated without a mutation to reconcile, but it still deserves ownership-safe output. An order_not_found result intentionally does not distinguish another customer's order from an absent one. Do not turn that privacy boundary into a troubleshooting disclosure.

A built-in request's open or resolved team state is separate again. Succeeded means Reesponder recorded the request. Resolved means staff marked its handling complete. Neither label independently proves a refund, courier change or provider update.