Apollo-tooling: codegen hangs in 2.18.0

[u-ashish]

Intended outcome:

Running client:codegen to generate GQL types from local project.

Actual outcome:

When running this command, it just hangs (I waited 40 minutes before giving up).

npx [email protected] client:codegen --localSchemaFile $GRAPHQL_SCHEMA_PATH --target 'typescript' --outputFlat --includes "server/src/**,frontend/src/**"  $OUTPUT_PATH

GRAPHQL_SCHEMA_PATH and $OUTPUT_PATH are local files one subdirectory down.

Please note that if if I use 2.17.4 instead of 2.18.0, it works perfectly under the exact same scenarios.

How to reproduce the issue:

I'm not sure how to help reproduce this because I don't want to share the codebase, but admittedly without more in-depth logging from the script, I can't pinpoint what might be causing the issue.

Is there a way to enable verbose logging as it runs codegen for me to see where it's hanging? With that I might be able to create a reproducible sample.

Versions

As mentioned above, it works for 2.17.4 but hangs for 2.18.0.

[patricknick]

In our setup, a single generation process takes about 10x longer until finished. Strangely the types seem to be outputted way earlier and after a reasonable amount of time, afterwards the hang occurs.

I'm not sure if it is related, but I noticed with version [email protected] (and probably all versions >2.18.0) it seems to do a lot of file writes in the background. Our create-react-app (respectively webpack) goes nuts during the code generation with countless recompilations until the point where you need to kill the terminal process. I supposed those are triggered due to file changes.
This happens only in combination with the Apollo code generation, when I downgrade to '2.17.4' again, it works as expected. It might be a hint on what's going on.

[schwer]

When I did some debug/tracing of the script, I observed the following problem in both 2.17.4 and 2.18.0. The asynchronous element of the codegen task for typescript is fetching the schema.

In the codegen task, I observed that all of the reads and writes from/to the file-system are done using the synchronous versions of the functions. As a test, I added an early exit (via process.exit(0);) at the conclusion of the logging statement here. The behavior seemed identical with that early exit.

What's keeping the process alive for the extra time?

[JakeDawkins]

Thanks for opening this @u-ashish This issue should be resolved with #1559 and 2.19.0 should have fixes for this. Let me know if not, and I can reopen :)

[u-ashish]

@JakeDawkins I can confirm this fixed my issue, thanks so much!