PohPanel: 'Failed to load exit portal config' logs at INFO twice per pathfinder refresh

[runsonmypc]

Summary

PohPanel.getAvailableTransports logs "Failed to load exit portal config" at INFO level whenever the user hasn't configured a Player-Owned House exit portal tile. PathfinderConfig.refresh calls into PohPanel twice per refresh (once for getAvailableTransports, once for getTransportsToPoh), so the message appears twice per refresh — hundreds of times per session for anyone without PoH configured.

Not a bug per se, but high-volume log noise that masks real issues during triage.

Location

runelite-client/src/main/java/net/runelite/client/plugins/microbot/shortestpath/PohPanel.java, line 212:

public static Map<WorldPoint, Set<Transport>> getAvailableTransports(Map<WorldPoint, Set<Transport>> allTransports) {
    if (instance == null) return allTransports;
    ...
    WorldPoint exitPortal = instance.tilePanel.getTile();
    if (exitPortal == null) {
        Microbot.log("Failed to load exit portal config");   // ← line 212
        return allTransports;
    }
    ...
}

This is not actually a "failure" — it's the expected state when the user hasn't clicked the "Detect available POH teleports" button yet. The method gracefully returns the input transports unchanged.

Repro in live log

20:46:11 EDT [QuestScript-3] INFO ... - Failed to load exit portal config
20:46:11 EDT [QuestScript-3] INFO ... - [PathfinderConfig] refresh: transports=360ms, restrictions=0ms, tabSwitch=0ms, total=360ms

Appears twice per PathfinderConfig.refresh call.

Suggested fix

Demote to debug (and/or phrase it as a normal-state notice rather than a failure):

if (exitPortal == null) {
    log.debug("PoH exit portal not configured; PoH transports unavailable");
    return allTransports;
}

If PohPanel doesn't already have an @Slf4j annotation, add one, so log.debug is available without going through Microbot.log (which always prints at INFO).

Optionally: surface a visual cue in the ExitTilePanel UI when the tile is unset, so users who do want PoH transports know they need to click the detect button.

Related

• Indirectly related to Rs2Walker: partial-path retry loop spins for ~1min when plane changes mid-walk (Integer.MAX_VALUE finalDist) #1 / Rs2Walker: partial-path logic has no upper bound — accepts 7000+ tile gaps as 'partial' #2 — during pathing investigations, this spam made it harder to spot the actual walker events in the log.