Both processed and unprocessed tags included in cache tag list

I can replicate this issue in D10.3 also in a view block.

Updated the MR to make it compatible with the latest code version.

@Berdir

I don't understand why they would get duplicated though. Sounds to me like you might have another view that doesn't have the same argument or not value for it?

I am having the same issue as everyone else when embedding a view on a page.

How to reproduce:

1. Add a view with a contextual filter.
2. Add custom cache tag for: my-custom-tag:{{ arguments.field_name }}
3. Add a custom page controller, and add an embedded view via: $render_array = Views::getView($view_name)->buildRenderable($display_name, [$arg]);
4. Visit the page
5. Inspect the results of $render_array['#cache']['tags'] and notice that the tokens remain un-resolved

After investigation, the following is occurring:

1. buildRenderable() will:
   • Call DisplayPluginBase::buildRenderable()
   • Which then calls DisplayPluginBase::applyDisplayCacheabilityMetadata()
   • Which then calls ViewExecutable::getCacheTags()
   • Which ultimately calls CustomTag::getCacheTags()
2. The issue here is that the arguments are not provided to DisplayPluginBase::applyDisplayCacheabilityMetadata() at this stage so there are no values to process the tokens with.
   • It is at this point where the raw un-resolved cache tags are added to the render array and ultimately stored in the DB
3. Then, when the view gets rendered, it first caches the results data:
   • View::preRenderViewElement() is called during render.
   • Which then calls ViewExecutable::executeDisplay()
   • Which then calls Block::execute()
   • Which then calls ViewExecutable::render()
   • Which, if storing new cache data calls CachePluginBase::cacheSet()
   • Which then calls CustomTag::getCacheTags()
4. NOW, since the view is built properly, the arguments are present and the tokens get processed correctly.
5. Further down the render pipeline, ViewExecutable::render() will then:
   • Call DisplayPluginBase::render().
   • Which then calls DisplayPluginBase::applyDisplayCacheabilityMetadata()
   • Which then calls ViewExecutable::getCacheTags()
   • Which ultimately calls CustomTag::getCacheTags()
6. BUT, the issue here is applyDisplayCacheabilityMetadata() is applying the cache tags to an existing element, and this element already contains the cache tags with the un-resolved tokens from the first call to CustomTag::getCacheTags(), so the element ends up getting both resolved and unresolved tags.

As for blocks, the process is the same, where ViewsBlock::build() will call DisplayPluginBase::buildRenderable().

I was playing around with modifying CustomTag::getCacheTags() in an attempt to extract the arguments from the element/render array before calling tokenizeValue():

if (empty($this->view->build_info['substitutions'])) {
  if (!empty($this->view->element['#arguments'])) {
    $this->view->setArguments($this->view->element['#arguments']);
    // This seems to be the only public way to call ViewExecutable::_buildArguments() without executing the view.
    $this->view->buildTitle();
  }
}

...Which seemed to work for embedded views where the arguments are passed into buildRenderable(), but I did not have luck with embedded blocks as it doesn't seem to have the arguments by the time it calls buildRenderable().

With my specific issues, the other proposed code in this issue queue seems to resolve the invalid cache tags, while retaining proper caching.

Since the issue is only in the initial render array building and the views render and views results caching end up providing the proper cache tags, changing CustomTag::getCacheTags() to omit the initial broken cache tags seems to have no ill effects.