This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
Ok so this is pretty frustrating. I have been building a macro to enable alteryx to have a direct line of communication with an API for a cloud based viz tool we use.
I have started to build macros in Alteryx and use python tool for when I need some python because this is wayyyyy quicker than building something via the python/html sdks. Generally this is great, however...
Today, when I got my macro working as a workflow (just running the yxmc with the test inputs) and had successful communication with the API, I went to test it as a macro tool in another workflow. It failed with the exact same inputs. The tool would also spit out different errors on different runs - sometimes RangeIndex obj isn't iterable, sometimes another object doesn't exist, etc.
I was unable to reproduce any of these errors in the macro. Eventually, I got an error that threw me a traceback in the macro. I copied it and put it into a text editor and, to my frustrated amazement, the macro had been running code from yesterday. No amount of saving (in jupyter or the macro itself) or restarting my computer fixed this. Eventually I deleted the tool and put my code into a new tool and now it works.
This has been frustrating so hopefully I can stop other people from being frustrated as well. Its pretty hard to debug code when your code is secretly replaced with an older iteration. I haven't been able to find a rewrite cache (or .pyc if that is what it is) anywhere either.
My frustration also stems from my process as when I was drafting my code, I had some blanket error handling (except:) which increased the amount of time before I realized the code was old.
Things that happened that could have contributed to this failure:
Sorry for the late response and thank you in advance for the help.
Here is the macro, though I am not sure if you will be able to reproduce this error.
I've been looking a little further into how/where Jupyter is managed and those jupyterPipes.json and ipynb files in ProgramData may have something to do with it. Like the macro is trying to read an old file while the workflow is read/writing with new or in memory file.
Additionally, the jupyterPipes.json files have created an issue with concurrently utilizing macros for us, as it appears a lock is place on the relevant jupyterPipes.json when the macro is run in one instance, causing a concurrent instance (like a runner file) to fail due to access denied/write failure.