When a request from chat does not arrive: states, log and no duplicates

In the run-up to Black Week, the shop and the checkout are not the only things under load; so are the systems behind them: customer management, ticketing, inventory management. A chat assistant that writes into these systems creates tickets, leads or callback requests there, and that is exactly where a slow interface becomes delicate. If a detail is missing when reading, an answer stays incomplete. If a write fails, however, it is unclear whether anything was created, and when in doubt the visitor clicks a second time. This article shows which states a writing call can take in XICBOT, what the visitor reads in each case, why the call ends at the deadline and nothing is retried, how a one-time key helps prevent duplicate entries and what goes into the log.

Enlarge graphic

Labels in the illustration

• Approval in the chat
• End state
• What the assistant says (example)
• proposed
• awaits a click
• confirmed
• Confirm
• Reject
• open too long
• executed
• Your request has been created.
• failed
• That did not work just now.
• deadline exceeded
• No reply in time, so I give no result.
• rejected
• Understood, nothing will be created.
• expired
• This proposal is no longer valid.
• One-time key
• A second click creates nothing twice
• Built from conversation, tool and input
• The lock sits in the database
• Log: one line per call
• 14:02:27
• ticket_create
• deadline exceeded
• error text only
• 14:05:03
• crm_lead
• executed
• result returned
• 14:07:40
• callback_note
• rejected
• nothing executed

Seven states of a writing action in the chat

Before Black Week: when the writing side stalls

In the weeks before Black Week, load does not rise evenly. Peaks often hit precisely the systems that run unnoticed in day-to-day business: the ticketing system that receives questions about orders, the customer management where leads are entered, and the inventory management that keeps stock and orders. An assistant connected to these systems through tool control feels this directly, because it sends its request at the very moment the visitor is waiting in the chat window. If a system answers more slowly than usual, that is annoying for a piece of information. For a process that is supposed to create something, it becomes an open question.

Whether the assistant reads or writes decides how serious a failure is. If a reading query fails to return, a detail is missing, such as a stock level, and the assistant answers without it. How it falls back in stages is described in the article on outages and fallback operation. A writing process faces three different kinds of damage: the chat reports a receipt that does not exist. The visitor clicks a second time, and the ticket exists twice. Or nobody can say afterwards what became of the request. These three cases are the subject here.

Seven states instead of done or not done

In XICBOT, a writing call executes nothing at first. It goes to the visitor as a proposal, with the sentence that names the action, the real values and two buttons underneath. Only a click on Confirm moves it forward. From then on it ends in one of several named states, and each of them answers the question of whether something came into being in your system in its own way. The page on custom functions lists seven states: proposed, confirmed, executed, rejected, expired, failed and deadline exceeded.

The last two rows are the decisive ones. Failed and deadline exceeded look similar to the visitor, but they mean different things to your team. A failure usually means the target answered, but not with success, or it could not be reached at all. In most cases nothing has been created then. If the error response comes from an upstream server, however, or the connection drops after sending, the request behind it may still have arrived. A deadline exceeded, by contrast, means no answer arrived at all. Whether the ticket was created on the other side anyway is something nobody in the chat knows at that moment. That is why the log keeps the two outcomes apart and records the error text, and why the call carries a one-time key, which we come to further below.

What the visitor reads in the chat

The visitor sees the state of the call in the same card that held the proposal before. So they do not have to read from the tone of an answer whether their request arrived. They do not get to see the technical error text: a general sentence takes its place, and the error text itself stays in the administration area. There are two good reasons for this. An error text from a third-party system does not help the visitor, and it can reveal details about your integration that have no place in the public chat.

An example on the custom functions page shows how this sounds in conversation. A visitor asks about their order, confirms the query, and the inventory management system does not answer within the deadline. The assistant then says, in essence, that it has no status and therefore names none, that it will not try again on its own, and asks whether it should pass the request on. The same pattern applies to writing processes. A good message at this moment usually contains these elements:

• What did not work, in one sentence and without jargon, for example: “The ticket could not be created just now.”
• No confirmation of receipt, neither after a failure nor after an exceeded deadline, and no substitute detail such as a case number that was never issued.
• What is still possible now: handover to a person, a new attempt by the visitor themselves or another contact route.
• No promise of when someone will get in touch. When a request is handled is decided by your business, not by the assistant.
• The reassurance that the conversation so far is kept, so the visitor does not have to tell anything twice.

The deadline: eight seconds, adjustable per tool

In XICBOT, a call into a connected system has a fixed deadline. By default it is eight seconds, and the value can be set per tool to between one and twenty seconds. When the deadline runs out, the call is over. It does not keep working in the background while the conversation moves on, and it ends in the state deadline exceeded. Every other error ends as failed. That includes a redirect, for example, because a target that redirects counts as unreachable.

The HTTP specification itself shows why a missing answer says nothing about the outcome. For the case in which an intermediary between two systems receives no timely answer, it has a status code of its own, the 504. If such an intermediary sits in front of your system, its 504 arrives at XICBOT as failed rather than as deadline exceeded, because something did answer. The outcome is then just as open. The definition speaks only of the missing answer and says nothing about whether the process behind it was carried out:

Anyone who knows the article on fallback operation will find a tighter time budget per external system recommended there for reading queries. That is a planning recommendation for information, not a product figure, and it does not contradict the default, because the deadline can be set per tool. For writing processes, there is a good case for not planning too tightly. A deadline that is too short turns a slow but successful creation into a call with an open outcome. A deadline that is too long keeps the visitor waiting without telling them why. Which value fits depends on how your system answers under load, and that can be measured before the peak arrives.

Why nothing is retried

The obvious move would be to simply send a failed call again. XICBOT does not do that: if a call fails or exceeds the deadline, it is not retried, neither immediately nor later in the background. The model sees the error text and is instructed to say that it did not work instead of inventing a result. This restraint has a reason that the HTTP specification sets down for requests that are not idempotent:

Creating a ticket is not an idempotent process: sent twice, it produces two tickets unless further precautions are taken. After an exceeded deadline, the assistant also does not know whether the first request arrived. An automatic second attempt would be guesswork at your team's expense in this situation. The decision therefore stays with people. The visitor can raise the request again and then confirms a new proposal, or they have it passed on to a person. After an exceeded deadline, handover is often the safer route: a new proposal tends to be worded differently, so it carries a new one-time key and can create a second case in the target system. What matters in a handover is described in the article on handing over to staff.

The one-time key: clicked twice, created once

Duplicate entries rarely come from bad intent. A visitor taps twice because the first reaction takes a while, a second tab is open, or the connection drops at the wrong moment. In XICBOT, every writing step that creates or changes a record therefore carries a one-time key. It is formed from conversation, tool key and sorted input via sha256, so the same request in the same conversation produces the same key. The lock against the double click sits in the database, not in the interface. The change from proposed to confirmed runs as a conditional write: two simultaneous clicks execute once, and the second is reported as a duplicate, not as an error. Inside XICBOT, this gives a process that is not idempotent by nature the property the HTTP specification describes as follows:

• Taking a request: name, email, phone and request go into the business inbox. If the same call is repeated, nothing is created twice.
• Lead in customer management (crm_lead): the double click is locked; whether a repeated call takes effect only once on the other side is decided by your system based on the key.
• Appointment: two clicks do not create two requests.
• Handover to a person: a lock built from conversation and input prevents the duplicate notification.
• Changing an order: the key travels in a header of the call so that the connected system can recognise a repeated call.
• Reading calls carry no one-time key. It is only needed where something can come into being.

The log: one line per call

Every call leaves a line, the executed one as well as the rejected and the failed one. The line is written before execution and updated afterwards. Nothing that did not come back is meant to appear in the log: if a call fails, no result is stored, only the shortened error text. The preview text the visitor read before clicking is stored when the proposal is created and is not regenerated later. What the log shows is therefore the same wording the visitor confirmed. A line also records the following:

• the tool, meaning the named action, such as ticket_create or callback_note
• the input, after everything not in the field schema has been trimmed away
• the result, limited to the fields the adapter names as its result, and shortened
• the duration of the call
• the approval path, meaning automatic or confirmed by the visitor (in test conversations and via the API: confirmed by the application); a rejection is recorded in the state
• the state in which the call ended and, in the case of a failure, the shortened error text

In the chat window, the widget shows less than the administration area: duration and approval path are missing there, and a general sentence replaces the error text. For follow-up, the administration area is therefore the place to go. There you see which calls were executed, rejected, failed or stopped at the cap. From that you can tell which deadline is set too tight, which system gives way under load and which action should be added next. How such tasks can be shared within a team is described in the article on roles and approvals in the team.

Preparing before the peak

Most of the questions in this article can be settled before Black Week rather than during it. With an integration through tool control, we run every process once before go-live, including the failure path. It makes sense to repeat this run before an expected peak, with a focus on the writing actions. The following points work as a framework:

• List all writing actions and record for each one which system it writes into and who is responsible there.
• Check the deadline per tool: is the value enough when the target system answers more slowly under load, or does a successful creation turn into a call with an open outcome?
• Ask whoever looks after the target system whether it evaluates the one-time key in the header.
• Trigger the failure path on purpose, once with a target that does not answer and once with a target that reports an error. Check which sentence appears in the chat and which line is created in the log.
• Try the double click: confirm twice, confirm in two tabs, and check that a single case exists in the target system.
• Decide who goes through the lines marked failed and deadline exceeded after a busy day, and how follow-up happens.
• Read the preview texts of the writing actions: does each one name the action so that a visitor knows what their click triggers?

Suitable test cases for go-live are listed in the article on acceptance testing. Before Black Week, a second kind of request comes along that creates nothing but takes a lot of time: the question of whether things will soon be cheaper. How an assistant handles it without inventing discounts is described in the article on questions about future discounts.

What the assistant deliberately does not do

• It does not execute anything writing without confirmation. Writing actions are hard-set to confirmation when they are created and changed, even if someone chooses automatic.
• It does not repeat a failed call and does not let one continue in the background.
• It names no result that did not come back and confirms no receipt that does not exist.
• It does not promise when someone will get in touch. That is for your business to decide.
• It does not move money. None of the delivered connectors makes payments.
• It carries out at most five calls per answer. The sixth is logged as capped, and the visitor reads a sentence of its own about it.

These limits are deliberate decisions, not unfinished work. Tool and API control belongs to the Custom package. Which of your systems provide an interface, which processes are writing and how the deadlines should be set are things we are happy to clarify in an initial conversation. The tool control page shows the path from proposal to the line in the log in detail.

Frequent questions