Investigate removing content-cache.yml, or refreshing it more frequently

[machow]

For RSConnect boards, there is a content-cache.yml file that maps content name (e.g. my-mtcars-pin) to its underlying RSConnect identifier (a content guid). However, because changes to the mapping between content and guid can come from multiple places (e.g. other laptops, the web UI) this cache can easily go stale.

Opening this issue to track content-cache related problems, and to track research into what the effects of removing content-cache.yml would be.

Here are some related issues:

• https://github.com/rstudio/pins-r/issues/604
• https://github.com/rstudio/pins-r/issues/609

Here are issues related to the other cache file, user-cache.yml:

• https://github.com/rstudio/pins-r/issues/594

Edit: just a quick note on the two caches to clarify this issue.

• user-cache.yml: each entry maps a <rstudio-guid> -> <username>
• content-cache.yml: each entry maps <username>/<content-name> -> rstudio-guid and url

[machow]

Potential paths that become slower when cache is removed:

• pin_meta (anything triggering rsc_content_find), where many users have content with the exact same name. (see this API call)
  • 1 API call to RSC GET v1/content?name=<name>find content x n_matches to convert user guid -> user name.
  • 1 API call to convert user guid -> name per content returned by above request.
• pin_search with many matching pins
  • For each result entry will make same underlying request as pin_meta
  • Note that we could improve by passing result entry's content_guid directly to v1/content/{guid} endpoint

[machow]

Last thing--if we tackle this alongside the pins-python issue of being able to use guids when looking up underlying paths, we can likely work out the fast implementations for looking things across both libraries.

• https://github.com/rstudio/pins-python/issues/79

[machow]

From what I can tell, there's no way to completely fix the slowdowns we'd hit by removing the cache, using the current RSC API, but it also might not be too bad?

The issue is that we have two options for going from / -> content :

• (1) API GET v1/content?name=<content_name>
  • issue: can return multiple entries (e.g. if multiple have content called "mtcars").
  • issue: the content payload does not contain the owner name (only their guid), so we have to look it up to filter multiple entries.
  • unusable solution: this route accepts a user <guid> parameter, but we only know <user_name>.
• (2) app endpoint GET /applications?filter=content_type:pin&search=<content_name>.
  • benefit: this payload includes the names of content owners
  • issue: this returns any content that contains <content_name>, so there could be a lot more to filter.

Because we lack a way to look up content from <user_name>/<content_name>, we have to either take approach (1) and look up each user name manually, or take approach (2) and potentially get a lot of results to filter. Option (2) seems like it would work fairly well?

(Option (2) is also not technically part of the API, so we may want to make sure it won't change?)

[hadley]

This is done by #667, right?

[juliasilge]

We wanted to try out using /applications?filter=content_type:pin&search=<content_name> for some things that are slower now like pin_search(). It's not technically part of the API but we chatted with Kelly about using it.

[juliasilge]

Oh gosh 🙈 we are already doing this:

https://github.com/rstudio/pins-r/blob/633e6e7c0a4f0168516ef10a4e9258e846f32d8b/R/board_connect.R#L345-L360

So yes, I believe this is all done now. ✅

[github-actions[bot]]

This issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with a reprex: https://reprex.tidyverse.org) and link to this issue.