So I have dual wans setup on my Tik but am experiencing a minor issue. When I start a constant ping to Google and then unplug WAN1, WAN2 continues the ping to Google with no issues. But when WAN1 comes back online then the ping stream stops. If I cancel the ping stream and then start it again then things are good again back on WAN1.

So same thing if I stream a video..... WAN1 goes off line and WAN2 picks up and continues without a problem. As soon as WAN1 comes back online the video feed is interrupted. As soon as I refresh the video feed it comes back online with WAN1.

What is the deal with this?

You forgot to include your setup. (/export file)

When WAN1 goes down, I think the connections associated with WAN1 are reset/dropped, and thus all clients will have to re-establish their connections.

When WAN1 comes back online, connections established out WAN2 DON'T get reset because WAN2 is still online. However the routing does in fact send packets out WAN1. TCP packets that hit the remote host will be dropped because the remote host does not have a connection with your WAN1 IP.

ICMP and UDP are considered connection-less, but because NAT is involved, the Mikrotik creates connection entries for ICMP and UDP so that it can translate inbound packets.

When a ping goes out WAN1, the Mikrotik will check the connections table. An ICMP 'connection' is defined by source ip (your private IP) and dest ip. This connection entry already exists in Mikrotik's connections table, so it's timeout is reset. However when the ping reply is received by the Mikrotik, there is no NAT information for WAN1 so the packet is dropped.

If you look at IP > Firewall > Connections, you'll notice an ICMP connection's timeout is reset to 10 seconds each time you ping the same remote host. If you stop pinging and wait 10 seconds, the connection entry expires and is removed. Then when you ping again, the connection entry gets recreated but now with NAT information for WAN1.

Mikrotik doesn't explicitly have a failover wan feature. So maybe you can't consider this a bug. But what to do?

If you do connection marking, and packet marking, you can have established connections continue going out WAN2 after WAN1 has been restored. New connections will go out WAN1. One advantage of connection/packet marking is that you can remote into your network from either WAN1 or WAN2. This can be handy if a case comes up where WAN1 is considered online, but not working. Such a case is when your ISP gateway is pingable but nothing further.

Other option is to use a script that detects when WAN1 is online again, then you can reset the connections table (or temporarily disable WAN2 for 2 seconds which will reset associated connections)

That makes sense, thanks for the explanation.

When WAN1 goes down, I think the connections associated with WAN1 are reset/dropped, and thus all clients will have to re-establish their connections.

When WAN1 comes back online, connections established out WAN2 DON'T get reset because WAN2 is still online. However the routing does in fact send packets out WAN1. TCP packets that hit the remote host will be dropped because the remote host does not have a connection with your WAN1 IP.

That is a configuration error. Part of the configuration for a dual-WAN setup should always be to route all traffic with an already-determined public source address to
the interface that it corresponds to. When that interface is down, ICMP "unreachable" should be returned to the client.
You are right in that this means that connections will have to be re-established. A well designed client will to that, because it gets the ICMP messages, in reasonable time.

The failover logic should only consider "new" traffic.

and what is the best solution for this problem?