brought the nodejs codegen build up to par with the golang codegen build
in testing the nodejs codegen, I actually happened upon a bug in the golang implementation. docker run -d backgrounds the entire docker container, which means that there is no guarantee that the code gen has completed prior to attempting the subsequent docker cp command. In addition, the container doesn't stay alive unless its foreground process stays alive. To solve for these race conditions, we override the container's original foreground process with tail -f > /dev/null so that it will be around until we kill it and then exec the code gen command synchronously prior to cping it. With both the golang and the python bindings, I never ran into this issue because the codegen was performant enough not to run into the race condition (not so for nodejs 😉 )
@bdferris-v2 sorry for the rapid pings, but I found a fun race condition in the implementation of update_generated_code.sh. not an emergency by any means, but would be good to patch up
nodejs
codegen build up to par with thegolang
codegen buildnodejs
codegen, I actually happened upon a bug in thegolang
implementation.docker run -d
backgrounds the entire docker container, which means that there is no guarantee that the code gen has completed prior to attempting the subsequentdocker cp
command. In addition, the container doesn't stay alive unless its foreground process stays alive. To solve for these race conditions, we override the container's original foreground process withtail -f > /dev/null
so that it will be around until we kill it and thenexec
the code gen command synchronously prior tocp
ing it. With both thegolang
and thepython
bindings, I never ran into this issue because the codegen was performant enough not to run into the race condition (not so fornodejs
😉 )