Providers' priority ignored due to distance

[mitasamodel]

Bug description
Trains choose the provider station with lower priority (-1000) even if there is another station with higher priority (+1000).

I have 2 providers stations with different priorities: +1000 and -1000. The "-1000" station is near the depot and requester station, the "+1000" station is far away.
Expected behavior: trains go to "+1000" station if there are items (above threshold), train limit is not exceeded.
What happens: trains more often go to "-1000" station first, they will go to "+1000" station only if "-1000" station gets unavailable (no items / train limits exceeded).

To Reproduce

1. Place a depot.
2. Place a provider station near the depot, set the priority to "-1000".
3. Place a requester station not far away.
4. Place another provider far away, set the priority to "+1000".
5. Fill both providers with items (full).
6. Set the requester station to request these items.
7. Train will go to nearest "-1000" station instead of intended farthest "+1000".

Setup image

LTN version
3.1.0

Part of the log

544.797 ... (UpdateStop) [5] - Privider_1 {1 (0x1)} provides item,electronic-circuit 157908(1000) stacks: 789(0), priority: -1000, min length: 0, max length: 0, trains en route: 
544.831 ... (UpdateStop) [5] - Provider_2 {1 (0x1)} provides item,electronic-circuit 127872(1000) stacks: 639(0), priority: 1000, min length: 0, max length: 0, trains en route: 

544.965 ... (OnTick) [6] - Available train capacity: 360 item stacks, 0 fluid capacity.
544.965 ... (OnTick) [6] - 57226 parsing request 1/1
544.965 ... (RequestProcessor:processRequest) [5] - request 1/1: 8000(1000) item,electronic-circuit to Sarge852 {1 (0x1)} priority: 0 min length: 0 max length: 0
544.965 ... (update_dispatcher_provided) [5] -   item,electronic-circuit, 8000 in 40 stacks
544.966 ... (TrainLeaves) [5] - Train [8] "PuppetMuncher": left Depot [39] "Depot".

544.997 ... (OnTick) [6] - Available train capacity: 240 item stacks, 0 fluid capacity.

545.264 ... (UpdateStop) [5] - Privider_1 {1 (0x1)} updating provided count with delivery: item,electronic-circuit 158124-8000=150124
545.264 ... (UpdateStop) [5] - Privider_1 {1 (0x1)} provides item,electronic-circuit 150124(1000) stacks: 750(0), priority: -1000, min length: 0, max length: 0, trains en route: 8
545.297 ... (UpdateStop) [5] - Provider_2 {1 (0x1)} provides item,electronic-circuit 128088(1000) stacks: 640(0), priority: 1000, min length: 0, max length: 0, trains en route: 
545.331 ... (UpdateStop) [5] - Sarge852 {1 (0x1)} updating requested count with delivery: item,electronic-circuit -8000+8000=0

Full log file
factorio-previous.log

Save file
testLTN_Dispatch_Before.zip
The game is saved in editor mode (time is stopped).
Enable the combinator at requester station, the train will go to the wrong provider station.

[mitasamodel]

It looks like in the function compute_path(from_stop, to_stops, rev the only 1 provider is being selected using the pathfinder of Factorio:

local path_result = #to_stops > 0 and game.train_manager.request_train_path {
        type = 'path',
        starts = {
            {
                rail = from_stop.connected_rail,
                direction = rail_direction,
            }
        },
        goals = to_stops,
    } or nil

And only after that in main function RequestProcessor:processRequest the priority is checked (sorted by it):

-- 1) Establish all routes between possible providers and requesters.
-- 2) find all trains that can actually serve the routes    <= Here is the Factorio's pathfinder is applied (and only 1 station is selected)
-- 3) remove all providers that have no train going to it.
    --    Sort the result by priority, connection_count, active delivery count and item count

[mitasamodel]

Temporary workaround
The Factorio's station priority can be temporary used instead. But check the station name, if there are several stations with the same name and different priorities, then the LTN-trains start to go to wrong station...