search

windmill-labs / windmill

Open-source developer platform to power your entire infra and turn scripts into webhooks, workflows and UIs. Fastest workflow engine (13x vs Airflow). Open-source alternative to Retool and Temporal.
https://windmill.dev
Other
9.82k stars 457 forks source link

bug: Script Editor Test Runner overwrite python dependencies freezing to legacy version of wmill #3852

Open cerealkill opened 4 months ago

cerealkill commented 4 months ago

Describe the bug

Script Editor Test Runner overwrite python dependencies freezing to legacy version of wmill

IMPORTANT: This does not happen if I Deploy the script and then run it for the first time from the deployed script screen. BUT if I go back to editing the script and run "Test" it overwrites the dependecies file, causing errors when running the Deployed script.

To reproduce

Run a script from the Script Editor "Test" button.

Screenshot 2024-05-30 at 16 54 14

This forces python dependencies to freeze in older version of wmill, causing error like "Cannot import S3Object from wmill". I have to manually edit the dependencies file and delete the older version of wmill from workers pip cache to force it to download the required version from requirements.

Expected behavior

Screenshots

No response

Browser information

No response

Application version

windmill and workers version 1.338

Additional Context

No response

rubenfiszel commented 4 months ago

To give you context, the resolution at deploy time and the resolution when running in the test runner is exactly the same (it uses pip-compile on a set of requirements it has parsed from your imports) so I'm very surprised by what you're saying. Would you have something that is easier to reproduce on our side? Where do you see the error, at runtime or in the monaco editor itself?

cerealkill commented 4 months ago

I see the error at runtime. This simple script should create the error. But you have to make sure that it is a clean wmill deployment and that the workers /tmp/windmill/cache/pip was not previously stored otherwise it may contain a newer version of windmill already. Just create a new python script and tap "Test".

My bet is that is takes in account the existing wmill version cached there. 

import os
import wmill

from wmill import S3Object

def main(
    s3_resource: str = "f/minio/local-s3-instance",
    ):

    actor_data_fp = os.path.join("test", "actor_data")
    actor_data = wmill.load_s3_file(S3Object(s3=actor_data_fp))
    print(actor_data)
rubenfiszel commented 4 months ago

There is a cache for the resolution but it's in the database (pip_resolution_cache) and there is no reason why it would have picked an old version of wmill unless you're using an old index for your resolution (the default strategy is latest)

cerealkill commented 4 months ago

This older wmill==1.223.1 version is probably coming from your Docker file build instance.

rubenfiszel commented 4 months ago

I don't think so and again the deployment of a script and its test preview use the same resolution. Is there anyway for us to reproduce the issue from a fresh instance?

cerealkill commented 4 months ago

Ok, I will only have time to explore this bug next week, but I have this instance since Wednesday, and it has resolved many different packages, and it keeps resolving version 1.223.1 of windmill if I hit "Test" before I hit "Deploy" in the editor.

Here is a list of worker cached pip packages. I keep deleting wmill==1.223.1 and it keeps coming back because of the bug. The bug may be related to how pip-compile resolves this on my machine, but since this is a fresh Ubuntu 22.04.4 LTS, other people may be experiencing the problem as well.

$ ll ./deploy/local/storage/windmill/cache/pip/
total 228K
drwxr-xr-x 4 root root 4.0K May 31 09:32 'aiofiles==23.2.1'
drwxr-xr-x 4 root root 4.0K May 31 09:32 'aioshutil==1.4'
drwxr-xr-x 4 root root 4.0K May 30 15:42 'anyio==4.4.0'
drwxr-xr-x 4 root root 4.0K May 31 09:32 'apify==1.7.1'
drwxr-xr-x 4 root root 4.0K May 31 09:32 'apify-client==1.6.4'
drwxr-xr-x 4 root root 4.0K May 30 15:42 'apify-client==1.7.0'
drwxr-xr-x 4 root root 4.0K May 30 15:42 'apify-shared==1.1.1'
drwxr-xr-x 4 root root 4.0K May 30 16:53 'argon2-cffi==23.1.0'
drwxr-xr-x 4 root root 4.0K May 30 16:53 'argon2-cffi-bindings==21.2.0'
drwxr-xr-x 4 root root 4.0K May 31 09:37 'beautifulsoup4==4.12.3'
drwxr-xr-x 4 root root 4.0K May 31 09:37 'cachetools==5.3.3'
drwxr-xr-x 4 root root 4.0K May 30 15:42 'certifi==2024.2.2'
drwxr-xr-x 4 root root 4.0K May 30 16:53 'cffi==1.16.0'
drwxr-xr-x 5 root root 4.0K May 31 09:37 'charset-normalizer==3.3.2'
drwxr-xr-x 4 root root 4.0K May 31 09:32 'colorama==0.4.6'
drwxr-xr-x 4 root root 4.0K May 31 09:32 'cryptography==42.0.7'
drwxr-xr-x 5 root root 4.0K May 31 09:37 'google==3.0.0'
drwxr-xr-x 4 root root 4.0K May 31 09:37 'google-api-core==2.19.0'
drwxr-xr-x 5 root root 4.0K May 31 09:38 'google-api-python-client==2.130.0'
drwxr-xr-x 5 root root 4.0K May 31 12:01 'google-api-python-client==2.131.0'
drwxr-xr-x 4 root root 4.0K May 31 09:38 'googleapis-common-protos==1.63.0'
drwxr-xr-x 4 root root 4.0K May 31 09:38 'google-auth==2.29.0'
drwxr-xr-x 4 root root 4.0K May 31 09:38 'google-auth-httplib2==0.2.0'
drwxr-xr-x 4 root root 4.0K May 30 15:42 'h11==0.14.0'
drwxr-xr-x 4 root root 4.0K May 30 16:27 'httpcore==0.17.3'
drwxr-xr-x 4 root root 4.0K May 30 15:42 'httpcore==1.0.5'
drwxr-xr-x 4 root root 4.0K May 31 09:38 'httplib2==0.22.0'
drwxr-xr-x 5 root root 4.0K May 30 16:27 'httpx==0.24.1'
drwxr-xr-x 5 root root 4.0K May 30 15:42 'httpx==0.25.2'
drwxr-xr-x 4 root root 4.0K May 30 15:42 'idna==3.7'
drwxr-xr-x 4 root root 4.0K May 30 16:53 'minio==7.2.7'
drwxr-xr-x 4 root root 4.0K May 31 09:38 'protobuf==4.25.3'
drwxr-xr-x 4 root root 4.0K May 31 09:38 'proto-plus==1.23.0'
drwxr-xr-x 4 root root 4.0K May 31 09:32 'psutil==5.9.8'
drwxr-xr-x 4 root root 4.0K May 31 09:38 'pyasn1==0.6.0'
drwxr-xr-x 4 root root 4.0K May 31 09:38 'pyasn1-modules==0.4.0'
drwxr-xr-x 4 root root 4.0K May 30 16:53 'pycparser==2.22'
drwxr-xr-x 4 root root 4.0K May 30 16:53 'pycryptodome==3.20.0'
drwxr-xr-x 4 root root 4.0K May 31 09:32 'pyee==11.1.0'
drwxr-xr-x 4 root root 4.0K May 31 09:38 'pyparsing==3.1.2'
drwxr-xr-x 4 root root 4.0K May 31 09:38 'requests==2.32.2'
drwxr-xr-x 4 root root 4.0K May 31 12:01 'requests==2.32.3'
drwxr-xr-x 5 root root 4.0K May 31 09:38 'rsa==4.9'
drwxr-xr-x 4 root root 4.0K May 30 15:42 'sniffio==1.3.1'
drwxr-xr-x 4 root root 4.0K May 31 09:32 'sortedcollections==2.1.0'
drwxr-xr-x 4 root root 4.0K May 31 09:32 'sortedcontainers==2.4.0'
drwxr-xr-x 4 root root 4.0K May 31 09:38 'soupsieve==2.5'
drwxr-xr-x 4 root root 4.0K May 30 16:53 'typing-extensions==4.12.0'
drwxr-xr-x 4 root root 4.0K May 31 09:38 'uritemplate==4.1.1'
drwxr-xr-x 4 root root 4.0K May 30 16:53 'urllib3==2.2.1'
drwxr-xr-x 4 root root 4.0K May 31 09:32 'websockets==12.0'
drwxr-xr-x 4 root root 4.0K May 31 14:01 'wmill==1.223.1'
drwxr-xr-x 4 root root 4.0K May 31 09:38 'wmill==1.338.0'
drwxr-xr-x 4 root root 4.0K May 30 16:27 'wmill==1.338.1'
drwxr-xr-x 4 root root 4.0K May 30 16:53 'wmill==1.339.1'
drwxr-xr-x 4 root root 4.0K May 30 15:42 'wmill==1.339.2'
drwxr-xr-x 4 root root 4.0K May 31 13:46 'wmill==1.340.0'
rubenfiszel commented 4 months ago

The cache here as nothing to do with resolution, it's a pure pip cache.

The resolution itself depends only on 2 things: The resolution cache stored in pip_resolution_cache and the imports constraints that are present in your script.

So 2 possibilities, the imports of your scripts that you are testing have a constraint for that particular version somehow The pip_resolution_cache has a value for that set of constraint with an old value of wmill

If we can reproduce it, we will be able to fix it shortly but it's really the first time we find something like that

cerealkill commented 4 months ago

Thanks for the reply. I will look into it. Can I disable the automatic resolution, so that I write my own .lock files?