How to bypass generating config.json before starting the router

[salindah]

I started to use Wundergraph setup since a few months ago, everything was working fine until I updated the repository last week.

Now, it requires me to run ./compose.sh command and generate config.json fine under the directory of router/_schemas. I noted every time I do a change in one of the subgraphs, and publish, the change does not get applied in the schema. I also have to re generate this file and run the router.

This is actually a hassle and it kills the purpose. I didn't have to do such thing previously and straight away I publish the schema through the wgc command the changes were applied and I could query with the updated schema.

My question is, is there any way to bypass this static routing config file and be it dynamic as previously ?

Thanks in advance !!

[salindah]

I removed the configuration router_config_path: "./__schemas/config.json" as mentioned in the document in order to avoid using static router config.
But then when I start the router it tries to poll a configuration from the CDN server a few times and then fail.
The error I see when I execute the command is below.

`
{"level":"info","time":1731915039337,"msg":"Retry request","hostname":"Mac","pid":40065,"component":"@wundergraph/router","service_version":"dev","component":"router_config_client","retry":1}
{"level":"info","time":1731915041406,"msg":"Retry request","hostname":"Mac","pid":40065,"component":"@wundergraph/router","service_version":"dev","component":"router_config_client","retry":2}
{"level":"info","time":1731915045449,"msg":"Retry request","hostname":"Mac","pid":40065,"component":"@wundergraph/router","service_version":"dev","component":"router_config_client","retry":3}
{"level":"info","time":1731915053471,"msg":"Retry request","hostname":"Mac","pid":40065,"component":"@wundergraph/router","service_version":"dev","component":"router_config_client","retry":4}
{"level":"info","time":1731915069519,"msg":"Retry request","hostname":"Mac","pid":40065,"component":"@wundergraph/router","service_version":"dev","component":"router_config_client","retry":5}
{"level":"fatal","time":1731915069563,"msg":"Could not start router","hostname":"Mac","pid":40065,"component":"@wundergraph/router","service_version":"dev","error":"failed to get initial execution config: Post "http://localhost:11000/915c2ba5-9c35-49eb-86e9-bd2d4515d5f4/08e81404-fca8-4b7c-81ae-34465e9faea7/routerconfigs/latest.json\": POST http://localhost:11000/915c2ba5-9c35-49eb-86e9-bd2d4515d5f4/08e81404-fca8-4b7c-81ae-34465e9faea7/routerconfigs/latest.json giving up after 6 attempt(s)","stacktrace":"github.com/wundergraph/cosmo/router/cmd.Main.func1\n\t/Users/salindahettiarachchi/workspace/cosmo/router/cmd/main.go:109"}

`

[salindah]

An then I check the logs of the CDN docker instance in my local machine. And then I found this error. I am not sure how can proceed from here. Any help would be appreciated to fix this.

2024-11-18 08:30:38 <-- POST /915c2ba5-9c35-49eb-86e9-bd2d4515d5f4/08e81404-fca8-4b7c-81ae-34465e9faea7/routerconfigs/latest.json 2024-11-18 08:30:38 InvalidBucketName: The specified bucket is not valid. 2024-11-18 08:30:38 at throwDefaultError (/app/node_modules/.pnpm/@smithy+smithy-client@2.4.2/node_modules/@smithy/smithy-client/dist-cjs/index.js:838:20) 2024-11-18 08:30:38 at /app/node_modules/.pnpm/@smithy+smithy-client@2.4.2/node_modules/@smithy/smithy-client/dist-cjs/index.js:847:5 2024-11-18 08:30:38 at de_CommandError (/app/node_modules/.pnpm/@aws-sdk+client-s3@3.529.1/node_modules/@aws-sdk/client-s3/dist-cjs/index.js:4756:14) 2024-11-18 08:30:38 at process.processTicksAndRejections (node:internal/process/task_queues:105:5) 2024-11-18 08:30:38 at async /app/node_modules/.pnpm/@smithy+middleware-serde@2.1.3/node_modules/@smithy/middleware-serde/dist-cjs/index.js:35:20 2024-11-18 08:30:38 at async /app/node_modules/.pnpm/@aws-sdk+middleware-signing@3.523.0/node_modules/@aws-sdk/middleware-signing/dist-cjs/index.js:192:18 2024-11-18 08:30:38 at async /app/node_modules/.pnpm/@smithy+middleware-retry@2.1.4/node_modules/@smithy/middleware-retry/dist-cjs/index.js:320:38 2024-11-18 08:30:38 at async /app/node_modules/.pnpm/@aws-sdk+middleware-flexible-checksums@3.523.0/node_modules/@aws-sdk/middleware-flexible-checksums/dist-cjs/index.js:173:18 2024-11-18 08:30:38 at async /app/node_modules/.pnpm/@aws-sdk+middleware-sdk-s3@3.525.0/node_modules/@aws-sdk/middleware-sdk-s3/dist-cjs/index.js:97:20 2024-11-18 08:30:38 at async /app/node_modules/.pnpm/@aws-sdk+middleware-sdk-s3@3.525.0/node_modules/@aws-sdk/middleware-sdk-s3/dist-cjs/index.js:120:14 { 2024-11-18 08:30:38 '$fault': 'client', 2024-11-18 08:30:38 '$metadata': { 2024-11-18 08:30:38 httpStatusCode: 400, 2024-11-18 08:30:38 requestId: '1808FF8D209C599C', 2024-11-18 08:30:38 extendedRequestId: 'dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8', 2024-11-18 08:30:38 cfId: undefined, 2024-11-18 08:30:38 attempts: 1, 2024-11-18 08:30:38 totalRetryDelay: 0 2024-11-18 08:30:38 }, 2024-11-18 08:30:38 Code: 'InvalidBucketName', 2024-11-18 08:30:38 Resource: '/cosmo%7D/915c2ba5-9c35-49eb-86e9-bd2d4515d5f4/08e81404-fca8-4b7c-81ae-34465e9faea7/routerconfigs/latest.json', 2024-11-18 08:30:38 RequestId: '1808FF8D209C599C', 2024-11-18 08:30:38 HostId: 'dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8'

[Aenimus]

Hi @salindah,

Your router receives the execution config in one of two ways:

1. statically—you compose with wgc router compose and reference the file in your .env (see these docs).
2. through a CDN—Cosmo Cloud uses our CDN; in self-hosted you'd have to host it as part of the stack.

You can't mix and match these two approaches.

Does this answer your question?

[salindah]

Hi @Aenimus ,
Thanks for the response. I re-installed everything from the scratch. And it went away.

[Aenimus]

@salindah Sorry for the trouble, but it's great to read that it's sorted now.

[Aenimus]

I missed your follow up comments. I'm not sure what's gone wrong in your set up, and it could take some time to debug. I would advise to start from a clean slate. If everything is set up correctly, your router should use your local CDN as before, and changes will be propagated.