A frozen Teen Patti screen does not tell you whether the last action reached the service. Before repeating it, separate what you tapped, what the screen displayed and what the service later records for the same hand. This is a troubleshooting method, not a promise that a disconnected hand will be cancelled or refunded.
Separate three different kinds of evidence
Your phone can respond to a tap before a remote service confirms anything. A highlighted button is evidence of a visible change, not by itself a complete action receipt. Likewise, recovering a network connection does not tell you what happened during the interruption.
MDN's network-status documentation explains that a browser can consider a device online when it is connected to a local network without usable internet access. An online indicator is therefore only a hint, not confirmation that a particular service is reachable.
A separate technical example shows why sending and completion must not be confused. MDN documents WebSocket.send() as adding data to a transmission queue; calls made on a closing or closed connection discard the data. This does not establish that your app uses WebSockets. It illustrates why a screen response alone cannot identify the remote outcome.
| Observation | What it establishes | Still unknown |
|---|---|---|
| You tapped once | Your intended action | Whether it was received |
| The button changed appearance | The displayed response | Whether the service accepted it |
| A record identifies the same hand and action | What the service reports for that hand | Any disputed timing or correctness |
Preserve the hand identity before changing the screen
Record the displayed hand or round identifier, the table or mode name, the exact message and the time with its time zone. Note the last action you intended and whether you tapped again. If there is no visible identifier, say so rather than substituting a lobby name as if it uniquely identifies the hand.
Save a private screenshot if doing so is safe. Do not share passwords, login codes or other players' private information. Avoid clearing storage, reinstalling or discarding the screen before saving the relevant details: those actions may remove useful local context without resolving the disputed remote record.
Do not repeatedly press an action button to test the connection. Without knowing how the product handles repeated requests, you cannot assume another tap is either harmless or necessary. Do not enter a new paid hand to reproduce the fault.
Check the same hand after reconnecting
Use the product's normal history or support route, if one exists, and look for the saved hand identifier. A newly loaded lobby or a later hand is not the record you are trying to reconcile. Check the action description and any status alongside the identifier, rather than inferring the action from a balance alone.
Consider a fictional example: you tap an action, the screen freezes, and a reconnect opens a different table. That different table proves nothing about the first hand. If history later shows the original hand but no clear action entry, the answer remains unresolved; do not turn an incomplete history display into a claim that nothing was received.
A useful support request is: "For hand [identifier], I tapped [action] once before [message]. The later record shows [entry]. Please confirm the recorded action and the applicable disconnection rule." Add the product version and approximate time. Keep observations separate from conclusions such as "the server ignored me" unless a reliable record establishes that.
Keep the outcome unknown when evidence is missing
No universal Teen Patti disconnection policy applies to every product. Automatic folding, timeouts, restoration and corrections require that product's actual rules and records. This information site cannot inspect operator accounts or reverse actions. If there is no usable history or support response, stop at "not confirmed" rather than guessing the result or risking more money to investigate it.