The mechanism here is common to all the trackers - there’s a buffer of queued events, and if a request fails, it stays in the queue to be retried later. When the tracker attempts to send any event, it will attempt to send the other events in the buffer also. There is no differentiation for different errors, all are treated the same.
The principle here is that every event tracked should land at the collector as soon as possible (within the batching configuration), without scope to drop events. The collector is built for availability - usually provisioned with multiple instances across multiple regions, and behind a load balancer. In the unlikely event that a collector does go down, this tracker mechanism prevents data loss even still.
If your tracker is getting 4XX or 5XX responses because of some misconfiguration (eg. a wrong endpoint), then the failed events will stay in the buffer until this issue is resolved. However once you update the app with a fix, they should be successfully sent to the newly configured endpoint (unless the new configuration changes the tracker’s namespace or replaces the tracker instance altogether).