> ## Documentation Index > Fetch the complete documentation index at: https://docs.hubtalk.ai/llms.txt > Use this file to discover all available pages before exploring further. # History, limitations and troubleshooting > What the call event feed shows, what the mechanism does not do, and what each symptom means. # History, limitations and troubleshooting ## What the call history shows Open **History** and the session you need. Next to the utterances the event feed carries **Pre-call function** and **Post-call function** events. Each one shows the status, the execution time, the names of the variables written, the row number, and the stage it ran at (before dialing, before the first reply, or late delivery). | What you see | What happened | | --------------------------------------------- | ----------------------------------------------------------------------------------- | | Success | the function ran, the variables are written | | Error | your system answered with an error; the text is next to it | | Timeout | it did not fit into the time allowed | | Skipped (budget exhausted) | the block ran out of time before its turn came | | "waiting for the result", then a second event | late delivery: the agent started speaking without waiting, the result arrived later | | "skipped by condition" | the **Run only if** condition was false; the expression is shown next to it | | "without analytics result" | the post-call function ran without waiting for the conversation analysis | Pre-call function events of outbound calls sit **above** the first utterance: they really did run before the number was dialed. ## Limitations * **Functions are never called mid-conversation.** Anything to be asked during the dialogue belongs to flow nodes on the canvas. * **An utterance already spoken is not replayed.** The agent uses late data in its next utterance rather than asking again after the fact. * **Inbound calls cannot be cancelled by a decision** — it only applies to campaign dialing. * **The block is never replayed.** A failed function does not break the call — the agent keeps talking without its data — but once the block is over it will not run again, and there is no delivery log. Retries of the HTTP request itself are the **Retries** field of the function form, 0 by default. Idempotency is on your side: the same call can reach you twice if finalization repeats. * **The number of functions in a block is not limited**, but no more than 16 run at the same time within one row — that is a server guard, not an authoring limit; how many fit into the budget is decided by the longest chain. * **Post-call functions share the queue with conversation analysis.** A long request delays the analysis of the calls behind it — keep the timeout as small as it can be. * **Function results do not travel anywhere.** They do not reach post-call analytics or the `call_ended` / `call_analyzed` webhooks; the webhook payload is unchanged. * **Post-analytics, knowledge bases, and webhooks are not edited from the pipeline** — those blocks show settings and lead to their forms. ## Troubleshooting | Symptom | Where to look and what it means | | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | A function with the status Timeout | it missed the block budget or its own timeout; on inbound calls wait for the second event with the final status | | Variables are empty, `_success = "false"` | check `_error` in the function event: network, status code, mapping | | The function "succeeded" but the variables are empty | the field in the response is named differently than in the mapping — check the JSONPath | | A "waiting for the result" event, then Success | late delivery worked; the data arrived after the first utterance, which is normal | | A "skipped by condition" event | the **Run only if** condition was false; the event carries the expression | | The decision had no effect, the event says the decision does not apply outside a campaign dial | the call did not come from a campaign; the decision works there only | | A warning about an unrecognized decision | `call_decision` carried a value outside `proceed` / `cancel` / `retry`, and the dial went ahead | | The campaign paused with the reason `function_cancel_share` | your system is cancelling everything; check it, and resume the campaign manually | | Functions appeared in the history tens of seconds after the call ended | the block waited for the conversation analysis; that is normal, the ceiling is 60 seconds | | The mark "without analytics result" | the wait elapsed, `analysis.status = pending` | | The "Longest chain" line exceeds the budget | lower the timeouts or put independent functions into one row | The boundary is simple: before the request is sent and after the response is received is our side; what happens inside your system and what it returns is yours.