Router - Apollo Voyager II

In Voyager I and II , when I try to start the router with the following command , I get an error "The term ‘APOLLO_KEY=service:airlock-test’ is not
recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

I am trying to start the router with the following command APOLLO_KEY=<APOLLO_KEY> APOLLO_GRAPH_REF=<APOLLO_GRAPH_REF> ./router --config config.yaml.

I tried running this in command prompt , in terminal and get the same error. I am not sure how to fix this error and start the router. Any help is appreciated. Thank you

Hi there @gangadhara - so sorry to hear that you’re encountering trouble running the router. You mentioned that you were seeing this error in the command prompt as well as somewhere else. Could you let me know where else you’re seeing this error, as well as the operating system you’re using? With these details I’m hoping I’ll be able to help troubleshoot a little bit better.

One other issue might be with a malformed APOLLO_KEY. In your example, you show a value of “service:airlock-test”. Just to verify, your actual APOLLO_KEY value should be much longer than this, as it’s meant to be a complex and unique string of characters. (No need to share that secret key here, I just want to validate that this is not the source of the problem!)

Thank you, and I look forward to hearing from you!

Liz

Hi Liz,
I tried to execute this command in command prompt and in VS IDE Terminal and got error in both places.
I am using Windows 11 OS
for the APOLLO_KEY – I put it as service:airlock-test for security purpose (my actual key is the one that we say in .env file , it has unique string of characters).

Thank You

Hello,

I am having the same issue.
I suspect it happens when the command is run from a windows terminal.
Is there any work around?

Update: So for now, I took the approach of storing the supergraph locally and running “./router --supergraph <file_path_of_Supergraph>”

That worked, but it means I will have to manually update the supergraph.