IssueTracker

It still crash with the latest version 2.2.1. I think the problem lies somewhere around this code

NavDestination node = i == 0 ? mGraph : graph.findNode(destinationId);

When i is 0, just return mGraph itself. When the deep link destination is a root of bottom_nav tab, the deeplink.length becomes 1. Which means this function still says there's no invalid Destination in deep link even if deepLink[0] is totally irrelevant tomGraph.

So this step passes and when findDestination() is actually triggered down the road, it won't find any destination and thus lead to unknown destination crash.

All NavControllers of bottom nav automatically call handleDeepLink() as part of onGraphCreated(). The problem arises the moment NavController whose graph is irrelevant to the root deep link destination calls handleDeepLink().

It still crashes with 2.3.0-alpha03 version but only if you try to deeplink to startDestination fragment inside navigation graph. Repro steps (described in #8, but lets repeat it in hope issue will be reopened):

1. download NavigationAdvancedSample
2. send pending intent to any startDestination screen, e.g.

val pendingIntent = NavDeepLinkBuilder(applicationContext)
                .setGraph(R.navigation.list)
                .setDestination(R.id.leaderboard)
                .setArguments(bundle) // no matter if it is empty in this use case
                .createPendingIntent()
pendingIntent.send()

Exception:

     Caused by: java.lang.IllegalStateException: unknown destination during deep link: com.example.android.navigationadvancedsample:id/list
        at androidx.navigation.NavController.handleDeepLink(NavController.java:689)
        at androidx.navigation.NavController.onGraphCreated(NavController.java:602)
        at androidx.navigation.NavController.setGraph(NavController.java:563)
        at androidx.navigation.NavController.setGraph(NavController.java:528)
        at androidx.navigation.fragment.NavHostFragment.onCreate(NavHostFragment.java:246)
        at androidx.fragment.app.Fragment.performCreate(Fragment.java:2684)
        at androidx.fragment.app.FragmentStateManager.create(FragmentStateManager.java:280)
        at androidx.fragment.app.FragmentManager.moveToState(FragmentManager.java:1175)
        at androidx.fragment.app.FragmentTransition.addToFirstInLastOut(FragmentTransition.java:1255)
        at androidx.fragment.app.FragmentTransition.calculateFragments(FragmentTransition.java:1138)
        at androidx.fragment.app.FragmentTransition.startTransitions(FragmentTransition.java:136)
        at androidx.fragment.app.FragmentManager.executeOpsTogether(FragmentManager.java:1989)
        at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute(FragmentManager.java:1947)
        at androidx.fragment.app.FragmentManager.execSingleAction(FragmentManager.java:1818)
        at androidx.fragment.app.BackStackRecord.commitNow(BackStackRecord.java:297)
        at com.example.android.navigationadvancedsample.NavigationExtensionsKt.obtainNavHostFragment(NavigationExtensions.kt:269)
        at com.example.android.navigationadvancedsample.NavigationExtensionsKt.setupWithNavController(NavigationExtensions.kt:61)
        at com.example.android.navigationadvancedsample.MainActivity.setupBottomNavigationBar(MainActivity.kt:121)
        at com.example.android.navigationadvancedsample.MainActivity.onCreate(MainActivity.kt:54)

Reopening would be a good sign that issue is recognized.

Just in a case Reopen feature is not implemented in IssueTracker :), new ticket is created: https://issuetracker.google.com/issues/151164638

Filing a new bug with a sample project that reproduces the issue you're still seeing is indeed the correct behavior. We don't support bug necromancy, particularly 30 releases after the original fix was shipped.

#13 i'm curious what went wrong w/ the Github setup. I don't want to hijack this bug but if you can either file an issue at https://b.corp.google.com/issues/new?component=923725&template=1480355 or directly reach out to me (yboyar at google), I would like to figure out why the setup didn't work for you.

I don't think I will add the test; ultimately I am unfamiliar with AOSP tooling and in particular the test setup for this, so it's an open-ended time commitment, and I already spent too much time on this tiny code problem.

I can still make a PR for the code change that fixes the bug (based on my testing via repro & actual app), but it's so trivial that you might just as well change it yourselves. As I mentioned in #10, the primary concern with the code change would be regressions, which are not captured by the envisioned test anyway, so I'd consider it defensible to go without test. The alternative, no fix, leaves TRUNCATE in a poor state.

I meant comment#11

are you still blocked on the SSH issue? FYI we do have other people sending PRs from Github without that issue so I would like to figure out what is broken in your case (as it might be affecting other people as well).

I want to respect your time though so if you don't want to deal with it anymore, you can send a PR without tests and we'll take it from there to add tests (though unfortunately, we cannot merge a PR without tests so we'll need to add them).

Thanks for your and Aurimas' help on the SSH issue last year, doing a checkout with filter and SSH caused the problems. I suggested updating the online instructions to point out this gotcha, not sure what happened after that on your end.

I am sending you a PR with the fix & added test. I gave it one more push to get if off my mind.