Invalid device names result in no response at all from API, causing applications using the API to hang

[tezdog]

Describe the bug
Invalid device names result in no response at all from API, causing applications using the API to hang

To Reproduce

1. Go to 'https://ad-apps.fnal.gov/plotting/'
2. Click on 'hamburger menu and login'
3. Click on + and enter m:outtmp (plot starts)
4. Click on + and enter m:outxxx (application hangs due to no response from API)

Expected behavior
I am not sure what is best, or cannonical behavior for a GraphQL API. Some sort of error message, or return the valid data and ignore the invalid, or something other than not responding at all.

Screenshots
n/a

Environment (please complete the following information):

• Firefox web browser, using controls proxy

Additional context
n/a

[cnlklink]

I think the fundamental problem here is that we have no way of knowing (yet -- pip2 is wokring on a device database) if a PV doesn't exist without waiting for a timeout on "pvget".

But we should have a timeout and that timeout should be relatively quick to ensure a good user experience - 2secs?

[clawrencefnal]

2 seconds sounds good. Lets try that and lets see how that works. @cnlklink

[rneswold]

I instrumented all the code paths from DPM and I'm not getting any messages. @charlieking65 says, while DPM waits for an IOC's reply, it sends ACNET_PENDs. However, Charlie thinks he didn't forward those PENDs over the gRPC channel.

The real solution is to time-out in a short amount of time (1 - 2 seconds.) I'll add a timeout to the GraphQL resolver, since we can't be sure DPM will behave correctly.

Even if I add my own timeout-, I'll leave this issue open because I need to make sure I'm handling the time-outs from DPM correctly.