Naillik•9mo ago

Background Runnable not triggering on App start

Hi, I have an App that loads the data it needs using a few background runnables that are configured to trigger on App start / refresh & input changes. However, none of these scripts are running when the app is loaded — I need to manually click the app refresh button to run them for the first time. When I do, they all run as expected without issue. I found this related thread (https://discord.com/channels/930051556043276338/1169575765063520326/1186334618681614396) but it seems that no cause was discovered. Any ideas as to what could be causing this?

12 Replies

rubenf•9mo ago

what version are you on and can you reproduce with a smaller app on app.windmill.dev ?

Naillik•9mo ago

Versions v1.266.1 and v1.269.0. I haven't been able to reproduce it with a smaller app. However, I've tried forking my app and removing all background runnables, replacing them with a single background runnable that takes no input with Run on start and app refresh toggled to true -- the script still does not trigger when I open the app or refresh the page, and needs to be manually refreshed to trigger the script.

rubenf•9mo ago

it' not related to the background runnables it's related to one of your component not initializating properly it's likely a windmill issue which we can very very quickly fix but we need a repo on app.windmill.dev

Naillik•9mo ago

Sorry, I've not been able to reproduce with a smaller app. However, I've noticed something strange while trying: From my original app (original), I forked an app forked and removed every component & runnable, and added a single runnable test_runnable, set to trigger on app start. test_runnable does not trigger when I open forked . I then created a new app (fresh), with the same test_runnable set to trigger on app start. test_runnable triggers successfully when I open fresh forked and fresh are identical when viewed in my browser, including in the App Editor. Then I pulled both forked and fresh with wmill sync pull --raw to compare. - The fresh.app.yaml accurately describes fresh as I view it in my browser. - The forked.app.yaml appears to describe the configuration found in original (which I had deleted from forked), as well as the newly added test_runnable.
Could this difference in app config files be related? I would expect forked.app.yaml to be basically identical to fresh.app.yaml, given that they appear identical in the browser. Sorry I can't get you an exact reproduction -- hope this can be of some use! So I found the intersection of fields in original.app.yaml and fields in forked.app.yaml. One-by-one, I removed those fields from forked.app.yaml, deploying and testing each time. After I removed a particular field (value.subgrids.r-0), the runnable correctly triggered on app start. When I added this subgrid back, the app reverted to the previous behaviour.

Naillik•9mo ago

Here is the removed field

removed-field.yml

rubenf•9mo ago

what is the component r itself ?

Naillik•9mo ago

This is the only other reference to r, present in both original.app.yaml and forked.app.yaml:

id: r
data:
  id: r
  type: containercomponent
  configuration: {}
  customCss:
    container:
      class: ''
      style: ''
  groupFields:
    label:
      type: static
      value: Content
      fieldType: object
  numberOfSubgrids: 1

id: r
data:
  id: r
  type: containercomponent
  configuration: {}
  customCss:
    container:
      class: ''
      style: ''
  groupFields:
    label:
      type: static
      value: Content
      fieldType: object
  numberOfSubgrids: 1

Neither original nor forked have a component with the ID r visible in the App Editor outputs panel, although the latest component ID in original is ai so presumably there was an r component at some point.

rubenf•9mo ago

in a previous version that we fixed 2 weeks ago, there were some cases were renaming a field could lead to this happening it's been fixed since but maybe that was the source

Naillik•9mo ago

Would this be the same reason that there was so much "invisible" content in my forked.app.yaml? Even after I've deleted every component & runnable in the app through the editor, my forked.app.yaml is still several hundred lines long, its fields a subset of those in original.app.yaml.

rubenf•9mo ago

yes possibly the bug would happen if you renamed a component to itself

Naillik•9mo ago

Great, I'll remove those fields from original.app.yaml , hopefully that'll fix it -- thanks for the help! Do you have a link to the PR? Would love to see what the fix was.

rubenf•9mo ago

the fix was literrally just making it impossible to attempt a self-renaming the issue would arise if an item was renamed <id> -> <id> which would happen very quickly if you clicked enter without changing the name