[neighorch]: Retry until inband port is available

[Xichen96]

What I did

NeighOrch previously asserted that an inband port always existed whenever it processed a remote-system-port next hop. This PR converts that boot-order assumption into the normal SWSS retain-and-retry behavior.

Root cause

Remote-system-port next hops must be normalized to the local inband interface. The original implementation called getInbandPort() and then asserted that the returned alias was non-empty.

That assumption has existed since the remote-system-port path was introduced in 2021. It is not guaranteed during initialization: a remote next-hop update can be processed before the local inband port has been configured.

The old behavior was:

remote next-hop event
→ inband port not ready
→ assert
→ terminate orchagent

An unavailable prerequisite is transient state, not an invariant violation.

Fix

Each remote next-hop path now checks the boolean result from getInbandPort():

remote next-hop event
→ inband port not ready
→ return false
→ retain work
→ retry after inband configuration is available

The check covers:

• normal next-hop creation;
• bulk next-hop completion;
• IP next-hop removal;
• MPLS next-hop removal.

No fallback alias or synthetic success is used. The operation reports retry and leaves the existing state machine responsible for reprocessing it.

Why I did it

SWSS orchagents routinely return false when a required object is not available yet. Treating inband-port boot order the same way avoids a process abort without hiding the missing dependency or programming an object against the wrong interface.

This defect predates the interface deletion and VRF-rehome work. It is kept separate from the inband RIF identity/bookkeeping fix because the two changes address different failure modes:

• identity/bookkeeping determines which RIF, key, and refcount represent a remote next hop;
• this PR determines what happens when that required inband interface does not exist yet.

Dependency

This branch is stacked on PR #4769 because that PR adds the bulk normalization path containing the third inband lookup. Until #4769 merges, GitHub's Files changed tab includes the prerequisite commit. The final upstream merge order is #4769 first, then this retry change.

How I verified it

Focused mock coverage configures a remote system port, removes the inband-port designation, and verifies that next-hop operations return false rather than asserting:

• addNextHop();
• processBulkAddNextHop();
• removeNextHop();
• removeMplsNextHop().

Route and label-route removal coverage also verifies that missing-inband MPLS dependencies are detected before any bulk SAI operation is queued. NhgOrch performs the same preflight before changing group or member state.

The available single-ASIC hardware testbed cannot exercise remote system ports, so this path is covered with focused unit tests and exact-head CI.

Current exact-head master PR build

• Head: b7c61bb6e2a9ef0b7af97a003b850b061439fa94
• Azure PR build: 1171077
• All architecture, ASAN, Docker, Trixie, Test vstest, and TestAsan vstest lanes passed.
• CodeQL, Semgrep, DCO, EasyCLA, all review threads, and the exact-head Copilot review are clean.
• No local build was used; validation is PR-build only.

202605 PR-build validation

• Validation-only PR: #4747
• The complete current-202605 stack applies PR [neighorch]: Track remote next hops on inband RIF #4769 first, includes batch-1 PR [neighorch]: Avoid inserting missing bulk neighbors #4772, and applies this retry change last.
• Exact validation head: d4b0502ecdac76d56fdf063a633045c0fb0de977
• Azure PR build: 1171672 — in progress.
• The Tested for 202605 branch label must remain absent until that exact result is complete.

Details if related

• Microsoft ADO: 38864639
• Required predecessor: PR #4769, remote-system-port inband RIF identity and bookkeeping.
• The assertion-to-retry issue is pre-existing and independent of PRs [intfsorch]: Fence new RIF dependencies during interface removal #4746 and [intfsorch]: Retry explicit router interface VRF rehome #4764.
• Merge batch 2, after batch-1 PRs [neighorch]: Track remote next hops on inband RIF #4769 and [neighorch]: Avoid inserting missing bulk neighbors #4772.

Review follow-up

• Bulk neighbor creation and both RouteOrch MPLS helper paths now propagate addNextHop() retry before advancing dependent work.
• Non-bulk and bulk neighbor deletion propagate removeNextHop() retry before refcount/cache progression.
• MPLS next-hop removal now returns retry instead of asserting when the inband port is unavailable.
• Route, label-route, and NhgOrch deletion preflight remote MPLS dependencies before submitting SAI operations or changing refcounts.
• Focused coverage verifies missing-inband add and deletion paths preserve retry state.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This PR updates NeighOrch remote-system-port next-hop handling to follow SWSS’s retain-and-retry model when the local inband port is not yet available during initialization, avoiding an orchagent abort caused by assertions.

Changes:

• Replace assert(getInbandPort()) with a boolean check and return false (retry) in remote-system-port next-hop add, bulk completion, and remove paths.
• Normalize remote-system-port next hops to use the inband alias consistently for RIF lookup and interface refcounting.
• Add focused mock tests to validate inband RIF usage and retry behavior when the inband port is absent.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
orchagent/neighorch.cpp	Converts remote-system-port inband-port dependency from assert to retry semantics; normalizes alias use for RIF/refcounting.
tests/mock_tests/neighorch_ut.cpp	Adds unit tests and SAI next-hop mocking to validate inband normalization and retry behavior.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

[mssonicbld]

This PR has backport request label(s) for branch(es): 202605, but is missing required test information. Please make sure you tick the tested branch(es) in the Tested branch section and provide test evidence (e.g., 202605: <test result>) in the Test result section as well in your PR description.

_{---Powered by SONiC BuildBot}

[rookie-who]

Hi — this PR has a cherry-pick conflict for the 202605 branch (Cherry Pick Conflict_202605). Could you please rebase or resolve the conflict so we can proceed with the cherry-pick?

If you need help identifying the conflicting changes, let us know. Thanks!

Comment by @vaibhavhd via automated tooling