sledge Comments - Windmill

sledge

•Created by sledge on 4/18/2025 in #help

Concurrency management for dedicated worker

So if I have two jobs ... and they each take 20s and they are queued very close to each other ... will they each show 20s in their "ran in" statement ... or will their "runtime" also include their "pulled but waiting" time?

6 replies

•Created by sledge on 4/16/2025 in #help

Collecting results within for-loop steps

Ahhh ... so above the "Collect result of each iteration" I just add a simple Action script that collects the results in an object and return that.

7 replies

•Created by sledge on 4/16/2025 in #help

Collecting results within for-loop steps

No description

7 replies

•Created by sledge on 4/16/2025 in #help

Collecting results within for-loop steps

@rubenf Is this doable? I thought maybe I could just stash the results iteratively - but its not clear where I could stash them. Unless this would require using setFlowUserState and then somehow at the end make the result be a call to getFlowUserState?

7 replies

•Created by sledge on 1/21/2025 in #help

Persisting state for incrementing counter

Ahhh, looks like maybe deleting the wmill-lock.yaml was the answer.

3 replies

•Created by sledge on 1/21/2025 in #help

Persisting state for incrementing counter

I tried adding --skip-resources to our command usage - it resulted in the resource types that we had in the repo getting deleted, but none of the resources, they all stayed there. I did a clean sync pull and that had no resources.

3 replies

•Created by sledge on 11/27/2024 in #help

Worker caching weirdness

One interesting tidbit - the bun requests used http 1.1 - deno used http 2.0

10 replies

•Created by sledge on 11/27/2024 in #help

Worker caching weirdness

And I agree - since this is just fetch getting executed by deno - this has to be a caching issue with the KV store.

10 replies

•Created by sledge on 11/27/2024 in #help

Worker caching weirdness

Well the response headers look pretty much the same from the deno requests as from curl: Response Headers: access-control-allow-origin: * content-type: text/plain date: Wed, 27 Nov 2024 15:21:36 GMT expires: Fri Dec 27 13:33:55 2024 GMT fly-request-id: 01JDQ3DAFZC30W8XJXY9HJGJ6D-sea kvdb-cache-status: HIT kvdb-edge-region: sjc server: Fly/d42d3a7f1 (2024-11-25) strict-transport-security: max-age=31536000; includeSubDomains; preload vary: Origin via: 2 fly.io x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-response-time: 0.490ms x-xss-protection: 1; mode=block Got 5 messages

10 replies

•Created by sledge on 11/27/2024 in #help

Worker caching weirdness

Those headers are from running curl here locally on my machine. I'm gonna see what the response headers look like on the weird responses.

10 replies

•Created by sledge on 11/27/2024 in #help

Worker caching weirdness

That is what I thought too ... how could this be a WM issue if they're just launching the script on a worker using the specified runtime.

10 replies

•Created by sledge on 11/27/2024 in #help

Worker caching weirdness

I tried both as a normal deno and normal bun.

10 replies

•Created by sledge on 11/27/2024 in #help

Worker caching weirdness

Maybe a bug in the response headers from the KV store? HTTP/2 200 server: Fly/d42d3a7f1 (2024-11-25) date: Wed, 27 Nov 2024 15:09:05 GMT content-type: text/plain kvdb-edge-region: iad vary: Accept-Encoding vary: Origin access-control-allow-origin: * expires: Fri Dec 27 14:01:15 2024 GMT strict-transport-security: max-age=31536000; includeSubDomains; preload x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-response-time: 0.467ms x-xss-protection: 1; mode=block kvdb-cache-status: HIT via: 2 fly.io fly-request-id: 01JDQ2PCK6MXMMG9KAP8ZJAQJ2-iad This is what I see from curl.

10 replies

•Created by itsupport505 on 8/26/2024 in #help

Has anyone run windmill via coolify?

Yeah - I pulled caddy out of the docker compose file and it ran fine under coolify.

6 replies