This is normal behavior for all tools in Alteryx, not only Python SDK tools. There are two solutions. One is fairly simple and the method used in 99.9% of built-in tools, so we'll start with that.
Quick background for you, somewhat simplified. When your tool is selected on the canvas and the configuration window is shown, a new instance of it is created. This new instance is initialized with the configuration settings it last had and the Alteryx engine expects a few other things to happen. When you click away from that tool, something called a configuration or update run happens across the canvas. The metadata from your tool is passed downstream through the workflow and each of the other tools updates if necessary. Think of it as running your workflow, but only on the metadata itself. Then that fresh instance of your tool is deleted. The whole process happens again the next time your tool is selected. That means nothing is persistent.
In your case, what you can do is this. If you are using the base Python SDK and not the Snakeplane wrapper, you can access the
alteryx_engine object passed into your tool in its
__init__ function. That object has a Boolean property called
UpdateOnly. Now, since your tool is an input tool, the engine will call your tool's
pi_push_all_records function. Inside that function, you check the value of
self.alteryx_engine.UpdateOnly. If True, then the engine is running the configuration / update run I described above. In that case, if possible, only download the data or metadata from the source that is required to set the metadata. If False, you are in an actual workflow run and your tool should do what it is already doing.
If downloading the data in each configuration run is too expensive and you must cache it, there are other workarounds. What a couple built-in tools have done (and I won't see which) is modify the actual configuration XML for the tool. This can be done in
pi_init and / or
pi_close. This is more complex, but works. This involves having an initially empty configuration field in the XML for a temporary file path that will contain your metadata. Once that metadata is generated and saved, set that path in
pi_init and / or
pi_close. If that field is not blank when reading your configuration XML in
pi_init, then load the metadata from that file (if it still exists). More complex, and maintaining that cache is a pain, but it can work.
Senior Software Engineer