[BUG] compound matching with grain in nodegroup fails when used with file_tree ext_pillar

Description
I use the file_tree ext_pillar to supply files to a group of minions using external pillars. I target the minions with a nodegroup definition in /etc/salt/master that uses a grain match. Only one of the minions is able to access the files as pillars. The rest of the minions report that the pillar does not exist.

Setup
In /etc/salt/master:

ext_pillar:
  - file_tree:
      root_dir: /srv/pillar
      keep_newline: True
nodegroups:
  nodegroup_a: 'G@mygrain:abc*'

In /srv/pillar, I have /srv/pillar/nodegroups/nodegroup_a/files/readme1.txt.

I have minions minion1, minion2, minion3, and they have mygrain: abc1, mygrain: abc2, mygrain:abc3, respectively, in /etc/salt/grains.

In /srv/salt/top.sls:

base:
  'minion1':
    - test
  'minion2':
    - test
  'minion3':
    - test

In /srv/salt/test/init.sls:

/tmp/readme1.txt:
  file.managed:
    - contents_pillar: files:readme1.txt

Steps to Reproduce the behavior
salt minion1 state.apply
salt minion2 state.apply
salt minion3 state.apply

Expected behavior
I expect /tmp/readme1.txt to show up on minion1, minion2, minion3. The file shows up on minion1. However, minion2 and minion3 report "Pillar files:readme1.txt does not exist".

If I replace nodegroup_a: 'G@mygrain:abc*' with nodegroup_a: 'L@minion1,minion2,minion3' in /etc/salt/master, everything works fine and all three minions are able to access the pillar files:readme1.txt.

To answer some of the obvious questions, yes, I have restarted the salt master and the salt minions. Also, the nodegroup targeting works fine. I can do salt -N nodegroup_a test.ping and all three minions return True.

Screenshots
If applicable, add screenshots to help explain your problem.

Versions Report

Salt Version:
           Salt: 3001

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.7.3
      docker-py: Not Installed
          gitdb: 2.0.5
      gitpython: 2.1.11
         Jinja2: 2.10
        libgit2: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: Not Installed
   pycryptodome: 3.6.1
         pygit2: Not Installed
         Python: 3.7.3 (default, Dec 20 2019, 18:57:59)
   python-gnupg: Not Installed
         PyYAML: 3.13
          PyZMQ: 17.1.2
          smmap: 2.0.5
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.3.1

System Versions:
           dist: debian 10 buster
         locale: UTF-8
        machine: x86_64
        release: 4.19.0-9-amd64
         system: Linux
        version: Debian GNU/Linux 10 buster

Additional context
Add any other context about the problem here.

Reproduce the issue with the shown /etc/salt/master nodegroup and ext_pillar configuration, /srv/pillar/nodegroups/nodegroup_a/files/readme1.txt, and the test state using contents_pillar. Start by tracing file_tree ext_pillar handling together with grain-based nodegroup matching, then compare it with the working minion-list matcher. Done means all three minions can retrieve files:readme1.txt through state.apply.