[go_router] Fix key collisions when sibling ShellRoutes coexist during push by Gorniv · Pull Request #11143 · flutter/packages

This PR fixes key collisions in go_router when push() navigates from one ShellRoute branch to a sibling ShellRoute branch under the same parent.

In that scenario, both shell branches can temporarily coexist in the widget tree. Before this change, that could cause framework assertions such as Multiple widgets used the same GlobalKey because:

  • _CustomNavigator was keyed with GlobalObjectKey(navigatorKey.hashCode), which could collide when two navigator keys had the same hashCode
  • ShellRouteMatch reused the configuration-time ShellRoute.navigatorKey
  • ShellRouteMatch.pageKey was derived only from route.hashCode, so multiple matches for the same ShellRoute could share page identity

This PR fixes the problem for regular ShellRoute by:

  • creating a fresh GlobalKey<NavigatorState> for each ShellRouteMatch
  • deriving a unique pageKey from that per-match navigator key
  • keying _CustomNavigator with GlobalObjectKey(navigatorKey) instead of GlobalObjectKey(navigatorKey.hashCode)

The change is intentionally scoped to ShellRoute only. StatefulShellRoute keeps its existing stable pageKey behavior because applying per-match page identity there can create duplicate StatefulNavigationShell instances with the same internal GlobalKey.

This PR also adds a regression test that reproduces the old crash by forcing a navigator key hash collision, verifies that pushing to a sibling shell route no longer crashes, and confirms that the previous shell route state is preserved after pop().

No screenshots are included since this is a routing/runtime fix rather than a visual UI change.

Pre-Review Checklist

  • I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
  • I read the [Tree Hygiene] page, which explains my responsibilities.
  • I read and followed the [relevant style guides] and ran [the auto-formatter].
  • I signed the [CLA].
  • The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
  • I [linked to at least one issue that this PR fixes] in the description above.
  • I followed [the version and CHANGELOG instructions], using [semantic versioning] and the [repository CHANGELOG style], or I have commented below to indicate which documented exception this PR falls under[^1].
  • I updated/added any relevant documentation (doc comments with ///).
  • I added new tests to check the change I am making, or I have commented below to indicate which [test exemption] this PR falls under[^1].
  • All existing and new tests are passing.