You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the amount of data to be queued exceeds the user agent limit (as defined in HTTP-network-or-cache fetch), this method returns false
It's somewhat fascinating that we are sometimes able to trace these errors (which contain the entire body of the failed beacon) using the beacon API. 🤔 I initially thought the problem was the size of individual beacon, but the docs say that it's rather a limit of what gets queued, which explains why we do manage to trace them after the fact.
I'll try to queue the beacons in smaller chunks, hoping that that prevents the total queue size from getting as big 🤔 and then we can compare the results in a few weeks to so if there are less failures.
The text was updated successfully, but these errors were encountered:
@hahn-kev good question. So, the main benefit of the beacon API is that requests don't get cancelled on navigation, but I just discovered that fetch with keepalive is an explicit replacement for that. So, I'll take a look.
We often get
sendBeacon - cannot send
errors in the browser console (honeycomb).This has to do with imposed data limits in the beacon API:
It's somewhat fascinating that we are sometimes able to trace these errors (which contain the entire body of the failed beacon) using the beacon API. 🤔 I initially thought the problem was the size of individual beacon, but the docs say that it's rather a limit of what gets queued, which explains why we do manage to trace them after the fact.
I'll try to queue the beacons in smaller chunks, hoping that that prevents the total queue size from getting as big 🤔 and then we can compare the results in a few weeks to so if there are less failures.
The text was updated successfully, but these errors were encountered: