[BUG] repeated lookup_jid on long running async orchestration causes its failure

Description
I use salt-api to launch an orchestration. It lasts 20 minutes to complete and I use runner_async to not incur in timeout.
As described in https://docs.saltproject.io/en/latest/ref/netapi/all/salt.netapi.rest_cherrypy.html#best-practices I then check if the job ended polling the jobs endpoint with jid returned by the runner_async command.

If the polling is scheduled every 15/30 seconds the orchestration fails.
If it is scheduled every 20 minute the orchestration ends successfully.

Sometimes it fails even if minion return success True.
Sometimes it fails because salt start the next job on the same minion before the previous ends.

Steps to Reproduce the behavior

I replicated the same issue using shell commands:

salt-run state.orchestrate <my-long-lasting-orch> --async
watch salt-run jobs.lookup_jid <jid>

Master Log:

2021-08-19 08:38:00,126 [salt.utils.lazy  :102 ][DEBUG   ][3847] LazyLoaded jinja.render
2021-08-19 08:38:00,127 [salt.utils.lazy  :102 ][DEBUG   ][3847] LazyLoaded yaml.render
2021-08-19 08:38:00,128 [salt.utils.entrypoints:56  ][DEBUG   ][3847] Using pkg_resources to load entry points
2021-08-19 08:38:00,138 [salt.utils.lazy  :102 ][DEBUG   ][3847] LazyLoaded local_cache.get_load
2021-08-19 08:38:00,140 [salt.utils.lazy  :102 ][DEBUG   ][3847] LazyLoaded local_cache.prep_jid
2021-08-19 08:38:00,143 [salt.utils.event :805 ][DEBUG   ][3847] Sending event: tag = salt/run/20210819063757948650/ret; data = {'fun': 'runner.jobs.lookup_jid', 'jid': '20210819063757948650', 'user': 'sudo_m
turra', 'fun_args': ['20210819063613093617'], '_stamp': '2021-08-19T06:38:00.142918', 'return': {}, 'success': True}
2021-08-19 08:38:00,145 [salt.utils.entrypoints:56  ][DEBUG   ][3847] Using pkg_resources to load entry points
2021-08-19 08:38:00,150 [salt.utils.lazy  :102 ][DEBUG   ][3847] LazyLoaded nested.output
2021-08-19 08:38:00,150 [salt.client.mixins:440 ][INFO    ][3847] Runner completed: 20210819063757948650
2021-08-19 08:38:00,150 [salt.transport.ipc:365 ][DEBUG   ][3847] Closing IPCMessageClient instance
2021-08-19 08:38:00,151 [salt.runner      :315 ][DEBUG   ][3847] Runner return: {}
2021-08-19 08:38:01,366 [salt.transport.ipc:365 ][DEBUG   ][31841] Closing IPCMessageSubscriber instance
2021-08-19 08:38:01,367 [salt.loaded.int.states.saltmod:365 ][WARNING ][31841] Output from salt state not highstate
2021-08-19 08:38:01,367 [salt.state       :321 ][ERROR   ][31841] {'out': 'highstate', 'ret': {'tst-at-cd-as01': False}}
2021-08-19 08:38:01,367 [salt.state       :2244][INFO    ][31841] Completed state [httpd_install_tst-at-cd-as01_1] at time 08:38:01.367386 (duration_in_ms=25484.098)
2021-08-19 08:38:01,376 [salt.state       :3281][DEBUG   ][31841] File /var/cache/salt/master/accumulator/140490811837576 does not exist, no need to cleanup

It seems that calling lookup_jid during the orchestration cause instability on the process.

Versions Report

Testes with salt-minion 3003.2 and salt-minion 3003.1

Salt Version:
          Salt: 3003.1

Dependency Versions:
          cffi: 1.14.3
      cherrypy: unknown
      dateutil: Not Installed
     docker-py: Not Installed
         gitdb: 4.0.7
     gitpython: 3.1.18
        Jinja2: 2.11.1
       libgit2: 1.1.0
      M2Crypto: 0.35.2
          Mako: Not Installed
       msgpack: 0.6.2
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: 2.20
      pycrypto: Not Installed
  pycryptodome: Not Installed
        pygit2: 1.6.1
        Python: 3.6.8 (default, Nov 16 2020, 16:55:22)
  python-gnupg: Not Installed
        PyYAML: 3.13
         PyZMQ: 17.0.0
         smmap: 4.0.0
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.1.4

System Versions:
          dist: centos 7 Core
        locale: UTF-8
       machine: x86_64
       release: 3.10.0-1160.31.1.el7.x86_64
        system: Linux
       version: CentOS Linux 7 Core

No source files or tests are named. Start by reproducing the issue with salt-run state.orchestrate --async and repeated jobs.lookup_jid polling, then trace the runner_async and jobs endpoint interaction using the provided master log. Done means long-running orchestration completes reliably while its JID is polled.