# Example casted after prodigy-update fires

**URL:** <https://support.prodi.gy/t/example-casted-after-prodigy-update-fires/7601>\
**Category:** Uncategorized\
**Tags:** front-end, solved\
**Created:** [August 15, 2025, 4:17pm UTC](https://support.prodi.gy/t/example-casted-after-prodigy-update-fires/7601 "2025-08-15T16:17:15Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Haris223](https://avatars.discourse-cdn.com/v4/letter/h/e9a140/32.png) [@Haris223](https://support.prodi.gy/u/Haris223)\
**Post date:** [August 15, 2025, 4:17pm UTC](https://support.prodi.gy/t/example-casted-after-prodigy-update-fires/7601/1 "2025-08-15T16:17:15Z")

</div>

Hello prodi.gy community 👋  
I am experiencing a weird error I’m not sure about its source.

Since I updated from 1.16 to 1.18 (same error with 1.17) I have the following issue:  
Often no task details are available in the UI for the current example. This also happens when I rerun with the same dataset, so that sometimes an example has task details and sometimes it doesn’t.  
The missing details result in my custom UI not rendering correctly.

When I start the Application with my custom recipe no prodigymount event is triggered (or not visible in the console) . When I answer the first question the console shows the following:

![image](https://us1.discourse-cdn.com/flex020/uploads/prodigy/original/2X/0/0dfebb5088f19330d02095f1dc02166ebe548c48.png)

Note here the _detail: null_  
Sometimes there are examples with the necessary detail (so basically the example itself) to render everything. In those cases prodigyupdate and prodigyanswer are triggered multiple times (up to 13 times per example).

What works is showing the text of the current example in the html I have to the left side of the UI.

With some debugging I came to the Idea, that prodigy might trigger the “prodigyupdate” event, before the stream is fully casted. Is that possible? Were there any changes in that regard since 1.16?  
Thats the JS I use to listen to the event:

```python
        document.addEventListener("prodigyupdate", event => {
            console.log("prodigyupdate", event);
            this.setProdigyTaskConfig(event.detail.task);
        });

```

after which I render my Interface:

```python
    setProdigyTaskConfig(taskConfig) {
        this.#taskConfig = taskConfig;
        this.#render();
    }

```

I hope I gave enough detail to the problem. If there Is any other thing I could provide please let me know.

Thanks in advance!

---

<div class="post-metadata">

**Author:** ![ines](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/ines/32/3_2.png) [@ines](https://support.prodi.gy/u/ines)\
**Post date:** [August 20, 2025, 8:08am UTC](https://support.prodi.gy/t/example-casted-after-prodigy-update-fires/7601/2 "2025-08-20T08:08:25Z")

</div>

Hi and welcome – and very cool to see a project making use of custom JavaScript UIs! We did extend the JS events in Prodigy v1.18 ([see changelog](https://prodi.gy/docs/changelog#v1.18.0)) so this was my first thought – although, that wouldn't explain why you're seeing the same behaviour in v1.17 🤔

One change in v1.18 is that there's now also a [`prodigyload`](https://prodi.gy/docs/custom-interfaces#javascript-events) event that fires after the app has mounted _and_ when custom JavaScript is loaded. So you could try using that intead of `prodigymount` and see if it resolves the problem?

(In general, it's definitely possible for the `prodigyupdate` event to fire multiple times until the example is ready, depending on whether new examples are fetched and what's needed to render the example in place. If you want to check whether it's a new example vs. an existing updated one, you can store the `_task_hash` property in a variable and check if it changed. But not 100% sure if this is relevant in your example from how I understand your use case.)

---

<div class="post-metadata">

**Author:** ![Haris223](https://avatars.discourse-cdn.com/v4/letter/h/e9a140/32.png) [@Haris223](https://support.prodi.gy/u/Haris223)\
**Post date:** [August 20, 2025, 1:59pm UTC](https://support.prodi.gy/t/example-casted-after-prodigy-update-fires/7601/3 "2025-08-20T13:59:39Z")

</div>

Hi Ines!  
Similar error occurs unfortunately with prodigyload. What I can report so far:

With prodigyload instead of prodigymount I exeperience the same error as mentioned initially. But when I set a timeout like:

```python
constructor(CustomSelector) {
        this.#CustomSelector = CustomSelector;
        document.addEventListener("prodigyload", event => {
            console.log("prodigyload", event, window.prodigy.content);
            this.#rootContainerNode = document.queryCustomSelector(CustomSelector);
            if (!this.#rootContainerNode) {

                const checkInterval = setInterval(() => {
                    this.#rootContainerNode = document.queryCustomSelector(CustomSelector);
                    if (this.#rootContainerNode) {
                        clearInterval(checkInterval);
                        this.#rootContainerNode.classList.add("custom-container");
                        this.#setup();
                    }
                }, 100);
                return;
            }
            this.#rootContainerNode.classList.add("custom-container");
            this.#setup();
        });
    }

```

I’m able to render the first example correctly and every following will be rendered broken initially, but when I refresh the page everything works fine.

Same wait function with "prodigymount” results in the first example not rendering correctly but like 80% of the following are rendered corretly instantly.

The wait function is actually (shame on me) vibe-coded, since I’m not really proficient in JS & web-developement. I will loop in someone who actually worked on the UI and wrote the code (with their bare hands), maybe that will give a bit more insights 🙂  
Thanks and best

---

<div class="post-metadata">

**Author:** ![\_adrian](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/_adrian/32/4634_2.png) [@\_adrian](https://support.prodi.gy/u/_adrian)\
**Post date:** [August 25, 2025, 9:08am UTC](https://support.prodi.gy/t/example-casted-after-prodigy-update-fires/7601/4 "2025-08-25T09:08:04Z")

</div>

> I will loop in someone who actually worked on the UI and wrote the code (with their bare hands)

Hey that’s me!

I did some testing by logging all events Prodigy emits to the console and compared the behavior between Prodigy 1.16.0 (which I last tested my custom UI on) and 1.18.2, which we are seeing this issue with after upgrading. For reference, this is the code producing the following outputs:

```javascript
["prodigymount", "prodigyload", "prodigyscriptload", "prodigyupdate", "prodigyanswer", "prodigyundo", "prodigysave", "prodigyspanselected", "prodigyend"].forEach(name => {
    document.addEventListener(name, e => {
        console.log(new Date().toISOString(), name, {
            "event.detail": e.detail,
            "window.prodigy.content": window.prodigy.content,
        });
    });
});

```

On 1.16.0, the output when stepping through an example dataset is shown below. `prodigymount`is emitted on initial load as well as every time the preloaded examples are exhausted and new examples are loaded from the server (we use a batch\_size of 3 here as well as instant\_submit:true). When the UI changes in any way, `prodigyupdate`is emitted (presumably as part of a React re-render?), and `prodigyanswer`when an answer is submitted - as configured with the batch\_size, 3 answers are submitted until new examples are loaded and a new mount event occurs.  
Importantly, during all of those events, the current task config is available - always in the global prodigy state, and apart from the mounts also in the emitted event’s details. This makes sense, as the prodigy task UI can only mount as soon as a task is actually there to display. So far so good.

 ![Screenshot 2025-08-25 at 10.31.33](https://us1.discourse-cdn.com/flex020/uploads/prodigy/original/2X/b/bc238f68264091b90c33e664c9444288a027d855.png)

* * *

Now, the output of the same script, but on 1.18.2. It’s immediately noticeable that the first time the page loads, all 4 events emitted at that time do not have any task config available. For `prodigyload` and `prodigyend`that would make sense, as at that time no task exists (yet), but even during the initial `prodigymount`no task config exists, which doesn’t make sense - if the UI is being mounted, there should be _something_ to render already. Presumably, Prodigy only populates the global state _after_ this event has been emitted in 1.18, whereas in 1.16 that happened before this event. As such, there is no way to get the current task config on page load without manually polling until `window.prodigy.content`is populated, or the ugly `setTimeout` hack Haris mentioned above.  
The same issue exists with the subsequent `prodigymount`events after a new batch has been loaded from the server.

 ![Screenshot 2025-08-25 at 10.34.03](https://us1.discourse-cdn.com/flex020/uploads/prodigy/original/2X/4/420fe78624fa4702f4614a6e0dea09309dd16102.png)

* * *

Overall, from my understanding it seems that `window.prodigy.content`is mistakenly populated after the mount event now, so there is no way to cleanly get the task config on initial (and subsequent) loads. The best fix IMHO would be to again have `window.prodigy.content` populated at the time `prodigymount`is emitted. An alternative (or combined) fix could be to populate `event.detail`during mount events to be consistent with the other events, which do all have the task as their detail.

P.S. I also checked with 1.17.5. There, no initial `prodigymount`event is emitted in the first place - in fact, no events at all are emitted during initial load. Submitting and re-fetching task batches does work correctly though, and `window.prodigy.content`is populated during subsequent mount events as with 1.16.0.

---

<div class="post-metadata">

**Author:** ![magdaaniol](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/magdaaniol/32/2787_2.png) [@magdaaniol](https://support.prodi.gy/u/magdaaniol)\
**Post date:** [September 1, 2025, 12:08pm UTC](https://support.prodi.gy/t/example-casted-after-prodigy-update-fires/7601/5 "2025-09-01T12:08:18Z")

</div>

Hi @Haris223 & @_adrian!

Thank you very much for a very helpful debugging info! I've traced the refactor we did in 1.18 and, indeed, there's a change with respect to the timing of the `window.prodigy` object update.  
In 1.16 `window.prodigy` object was being updated earlier in the cycle so it was available by the time `prodigymount` event was triggered  
Currently, `window.prodigy` object is being updated in `componentDidUpdate` method that emits `prodigyupdate` event.  
This new lifecycle prioritizes loading the app even though the first batch of the tasks may not be available yet which might often be the case if the tasks require some complex processing.  
While it makes a lot of sense in most scenarios, it is true that this change has compromised the timing guarantees of custom js scripts listening to events and we should have been more upfront about it - sorry!

Could you try listening to `prodigyupdate` event in your script? This is the only event that guarantees the task is available in the `content`.

---

<div class="post-metadata">

**Author:** ![\_adrian](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/_adrian/32/4634_2.png) [@\_adrian](https://support.prodi.gy/u/_adrian)\
**Post date:** [September 8, 2025, 8:57am UTC](https://support.prodi.gy/t/example-casted-after-prodigy-update-fires/7601/6 "2025-09-08T08:57:24Z")

</div>

Hi @magdaaniol, thanks a lot for taking a look! `prodigyupdate` does indeed always seem to have the task config available, but there’s one small issue: It doesn’t seem to be emitted during initial page load. In my screenshot above, it’s a bit hard to tell due to unfortunate timing, but the first time `prodigyupdate` is emitted is when I press the accept/reject button, which is 10 seconds _after_ the initial page load (26 seconds vs 36 seconds). As such, when using `prodigyupdate`, we still don’t get any information for the _initial_ task and can’t show our custom UI when loading the page for the first time. I think the fix here would be to also emit `prodigyupdate`when the very first task is loaded, and not just during subsequent tasks / user interaction (or perhaps that’s the intention anyways and doesn’t happen for some reason/bug?).

---

<div class="post-metadata">

**Author:** ![magdaaniol](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/magdaaniol/32/2787_2.png) [@magdaaniol](https://support.prodi.gy/u/magdaaniol)\
**Post date:** [September 11, 2025, 8:49am UTC](https://support.prodi.gy/t/example-casted-after-prodigy-update-fires/7601/7 "2025-09-11T08:49:44Z")

</div>

Hi @_adrian,

Just to let you know that we are revising how the events are emitted - you're right that the emission of `prodigyupdate` is inconsistent for the first task. We'll update as soon as possible. Thank you!

---

<div class="post-metadata">

**Author:** ![magdaaniol](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/magdaaniol/32/2787_2.png) [@magdaaniol](https://support.prodi.gy/u/magdaaniol)\
**Post date:** [November 24, 2025, 4:00pm UTC](https://support.prodi.gy/t/example-casted-after-prodigy-update-fires/7601/8 "2025-11-24T16:00:58Z")

</div>

Hi @_adrian,

It tool a bit longer than we'd hoped for but we have just released Prodigy 1.18.4 that fixes the issues with `prodigyupdate`. It should now fire consistently on the first task.