App Claims Module Output Not Defined

I have a module that shows red in the app where it is being used. When I hover over the red, it tells me: "statusSets is not defined", which is one of the outputs of the module.


The second screenshot shows that the statusSets output has a value, and that the javascript transformer that generates the output has no dependencies. It's just basically a way to access some common values.

So, I don't understand why my app thinks this output is undefined. Any thoughts?

Hey @nl-setech!

Is the statusSets output not showing in the state of the module?

I'm also curious to know if newly created instances of the module are showing the same error. It has happened before that deleted properties on a module have caused innocuous errors to display. Not sure that's the case here but as that's still an open issue, it might be something worth exploring.

I just ran into the same issue, and indeed deleting the existing copy of the module and then re-adding it fixed the problem.

Edit to add: Also, you must change the module name. If you use the same name, the app once again doesn't understand that the module was updated.

This is a pretty egregious bug.

Edit 2: Never mind on that. Refresh the editor and the error messages come back. Sigh.

Edit 3: After previewing the app, the editor now seems happy again. Strange.

Hi Kabirdas,

Well, the problem went away, so I didn't really have any way of answering your question for more detail, but then it came back.

It came back when I modified the module pretty heavily, including removing a couple of outputs. I deleted and re-added the module to the app, and corrected the references. Oddly, the same "statusSets" is giving the same problem again. I checked the state on the module this time, and you are right - the statusSets output is not in the list.

Then, I previewed the app, went back into edit mode, and now it looks like that fixed the problem this time.

Got it, thanks both of you for sharing your experiences with it. The dev team is currently focused on other functionality within Retool but they are planning to take a closer look at modules this year and this particular bug is on their radar. I've bumped it with them though and can report back here when there's a fix. As mentioned, the error should be innocuous though it can certainly make for a frustrating editor experience.

Hi Kabirdas, I find this a very breaking bug and renders modules almost unusable for things not intended to use by myself. it comprises the stability quite seriously.

Sure, after a few refreshes it works. But at any point it can also randomly break so if i have multiple modules i need to go rounds and check if they are in a breaking state constantly. It is a very serious problem for people using modules extensively and goes against the whole philosophy of modules themselves.

@Xiaolei_Zhu when did you first notice the behavior? It also sounds like you're seeing this on a fairly consistent basis, would you mind if I step into your org to take a look so we can better reproduce this?

@Kabirdas I am not the original poster, but I am experiencing the same issue, with a brand new App (and Module) that I am working on at the moment. I can see that the module output is available in the state however Retool intermittently reports that the output is not defined and therefore the behaviour relying on it does not work. The problem appears to be that the state (as reported by the debug output) does not accurately represent the state seen by the app when accessing a Module output.

I can't grant access to the organisation, unfortunately. Here's a couple of screenshots where the instance of my Module is sam_test:

  1. The error (which is also displayed in the Linter as sam_test is not defined):

Screenshot 2023-04-12 at 15.34.53

  1. The Disabled field relying on the Module output (Module instance sam_test, output locked):

Screenshot 2023-04-12 at 15.35.24

  1. The App state showing that sam_test exists, and has a locked output with a value of false:

  1. A full(er) view of the Module state showing the values expected:

Something that has jumped out at me while assembling these screenshots is that in the state for the module, there's inputs displayed that I deleted hours ago, so it looks as if the state I am seeing for the Module does not reflect the actual state. The inputs I deleted (which are visible in the screenshot) were called protect and type: neither appear anywhere in the Module any more.

I've also noticed that while the Module itself has no errors (when working with test inputs), it is showing linting errors when used within the App, linting errors like 'setting_value' is not defined (where setting_value is one of my inputs which can be seen in the screenshot).

I'm not sure what this means, but it seems to indicate that there's some issue between the App and the Module instance where the Module instance state can just... disappear? The Module instance still exists in the App, and I can manage it, and I can interact with it directly, but the App itself appears to be unable to communicate with it, as if it doesn't exist at all.

The workaround I've been able to identify is to delete the Module instance and then insert a brand new instance, and update references to it. After doing that, it seems to work again. My concern is that it feels like at some point the Module instance will end up becoming inaccessible to the App again, at a point in which I'm not editing it, but when people are actually using the App -- but I've only experienced this in editing mode so far, so perhaps it's limited to editing.

Hey @sam_ipinfo!

Thanks for giving such a detailed description of your setup. I'll try and cross-reference this with anything that looks similar to see if I can find some commonalities for a reproduction. It's good to hear that it only seems to be happening in editor mode so far but it's definitely reasonable to feel trepidation here - it's something to be fixed either way!

1 Like

I am running in the same issue. The scenario is:

  • A module is created.
  • A parameter is defined as 'output' in a module.
  • The module is placed in an app.
  • The output is referenced by a component in the app (e.g. a text component).
  • The value of the output is visible.
  • Closing the browser and re-entering in edit mode, the module instance is reported as missing or undefined.
  • Re-entering the reference to the module instance resolves the problem.
  • However, when closing the browser and re-entering, the module instance is again reported as missing again.

Sometimes it sticks and the reference to the module remains intact. But even the slightest editing causes the reference to the module to be lost again.

This behaviour currently renders the modules unworkable.

Thanks for the report @fmalotaux! We've been able to reproduce the issue and have created a bug report so the dev team will look into it. In the meantime - do you have a timeframe for when you first started seeing this behavior?

We just started using Retool a few days ago in a proof-of-concept. Our experience so far is favourable, except for this issue which we experienced right from the start.

Some extra information:

  • The problem seems related to changing the instance name.
  • Initially, when placing a module on the canvas, it gets a default instance name like myModule1.
  • When referring to this name, all seems to work fine.
  • However, when I change the instance name, e.g. myMainMenu, the following happens:
    • The new instance name is correctly referenced.
    • In preview mode, all is working fine.
    • But when closing the browser and opening again, the new instance name is not found.
    • Components that reference the module are not getting the data.

So, in conclusion, when leaving the initial module instance name intact, the problem does not appear. But after changing the instance name the problems start.

My "workable" workaround for the moment: don't change the default instance name.

Thanks for the added information @fmalotaux! There's a potential fix going out next week with the 2.120.0 release. Will ask to see if the behavior is still there once it's out!

1 Like

Just want to pass along an update that 2.120.0 has been released! If yall are still running into this issue please let me know!

1 Like