When I try to route fluids trough a pipe network with multiple fluid routers it will not go to the second fluid router or more there after.

For example if I build something like O=X=X=O where the O's are tanks, = is pipes and X is fluid routers. If I then make the tank on the left output a fluid it will not end up in the tank on the right.
If I replace the right fluid router with a tank the fluid does go into that tank so it seems that it goes through the first fluid router by itself just fine.

All of this is with using IE fuild pipes only and with no fluid routing filters set in the routers, setting them seems to make no difference.

This started happening when I updated from version 0.12-85 to 0.12-88 on a network of pipes that had worked fine before.

I know that this issue is closed but the same problem happens to me in 1.18.2 and i was thinking that it would be fixed considering this issue is for 1.12.2. I dont know what to do because i have to move fluids around manually and I was hoping to not do that.

I found a fix for it ,I used a wooden barrel to make the second fluid router think it was on its own system.

I've managed to diagnose the source of this issue. The FluidRouter has an internal safety to prevent infinite loops. The way that works is that it adds every router involved to the current running route to a list. The problem now is that our fluid pipes attempt two insertions. One to find all available outputs and then another one to actually do the transfer.

The conflict is that after the first one, the simulation, the router is marked as "busy", and thus rejects the second insertion.

I currently don't have an immediate idea for a fix on this, and would love to hear @malte0811's input, since I believe the cyclic routing protection as it currently stands was his addition.

The only fix I can think of right now would be to add a delay to the routers: add a small buffer to them and have them send the contents of the buffer in their own update call. I did get up just a few minutes ago, so there's a good chance I'll find some better alternative in a few hours.
Edit: I don't think there can be a better alternative apart from making the pipes not insert twice: The purpose of the safety is to prevent an exponential number of calls per tick. At each point where the fluid leaves a router and enters a pipe the number of calls multiplies by 2: as Blu said, one to check how much could be inserted, one to do the actual insertion. So a moderately long chain of routers and pipes (10-20 of each, somewhere between 1000 and 1000000 insertions per tick) could, if the routers don't buffer and don't block the second insertion, easily lag a server to death.

I can think of one alternative, but it's more of a workaround to make some more setups work than anything else: limit the number of insertion calls per router and tick (or per "outer" insertion call) to something like 16, rather than 1. That would make chains of up to 4-5 routers work, but no more than that.
Making pipes only insert once if only one output is available could also work, still not ideal though.