Reverse dependency not shown as I would have expected

[carols10cents]

Current Behavior

The shutdown-barrier crate doesn't show any reverse dependencies on its page: https://crates.io/crates/shutdown-barrier/reverse_dependencies

But this version of the stack-queue crate depends on shutdown-barrier as shown here: https://crates.io/crates/stack-queue/0.0.1-beta.16/dependencies

That version isn't yanked, but it is a prerelease? Do we not show rev deps that come from prerelease versioned crates...? Or is there something else wrong in this case? Or am I wrong??

Expected Behavior

I expected stack-queue to show up on shutdown-barrier's reverse dependencies page.

[Turbo87]

yeah, we only show reverse deps of the default versions of crates

[eth3lbert]

Yeah, and mostly due to performance considerations! If we'd like to provide this information, on my machine, the query execution time takes 3.x times longer (for serde, this comes to 800+ms). Though I'm not sure how it performs on the production db, from experience it would be even slower.

[carols10cents]

Yeah, that makes sense. I guess i have to be paying more attention to the admin crate delete tool that warns you when you're about to try to delete something with rev deps 😅

I can see this being an issue with people trying to delete their own crates as well and being told their crate can't be deleted because there are reverse dependencies but not being able to see the reverse dependencies?

I know there have been cases where crates owned by the same person depend on each other, so they actually could be eligible for deletion if you delete the leaf crates first, but unless you can see that it can be hard to figure out.

Could we possibly add some text to the rev deps page that says "reverse dependencies on the default version" and then have a link to "see dependencies on all versions" to run the slower query on-demand?

[eth3lbert]

I think all the suggestions make sense to me, and I can see that without this, the user might just send a support email asking for it. If we could give a url to navigate the user to inspect more details, it would mitigate the burden for the support team.

[eth3lbert]

then have a link to "see dependencies on all versions" to run the slower query on-demand?

Oh, and regarding this, we currently only show rev-deps on the default version, which implies that we unify versions. I suppose showing all versions here would display them without unifying them? And given that the records might become much larger, we probably also want to provide seek-based pagination for this endpoint?