Hey @launchable, any update on the issue with the message history not being set straight away?
I’m still having that issue where my pre-written chat messages don’t always load into the message history. Have spent ages trying to debug but sometimes it works and sometimes it doesn’t and seems completely random when
@gulbranson.nils - Hm, maybe I missed something in the video. It ended up being spliced together a bit awkwardly, so I may make another one soon that is tighter.
re: your screenshots, your workflow looks correct.
When you start a new conversation and generate messages, do they show up correctly?
And if you inspect the repeating group (in Debug / Inspect mode), do you see the message history being set? Or alternatively, if you run the workflow in debug mode, and look at the values that are being set, are they correct?
If the workflow seems to be setting the data correctly, maybe the issue is with how the repeating group is configured.
If you figure it out, please let us know, especially if it’s something wrong/missing in the tutorial, so I can add a note to the video.
The issue is still the message history is set quicker than the first records are saved (even though it’s a later action and there’s a pause before it) so is there anyway for the data container to act like a repeating group and auto-update as new db records are added?
@buildingsomething - I’m not sure what you mean by “the message history is set quicker than the first records are saved”. Do you mean you have a workflow that runs “Make changes to thing”, to modify a database record, then “Set Message History”, and that “Set Message History” is running before the DB action completes?
If so, that can happen with Bubble workflows; the actions don’t always run in order. There is a great post here from Bubble support on the topic:
The “custom event” approach is mentioned in that post, but basically the idea is, if you need things to run in a predefined order, you can “wrap” them in a Custom Event. So you create a custom event to run, e.g, Set Message History, and call that in your workflow where you need it, instead of just calling Set Message History directly. It’s a bit awkward, and non-intuitive, but it seems to work with Set/Clear Message History.
Another option (also covered in that post) is to have steps depend on results of previous steps. So, you could do something like:
Create a DB record in Step 1, and set its “message history” field
Then call Set Message History, setting the value to the “Result of Step 1’s Message History” (or w/e you called the DB field)
or something along these lines.
re: the Data Container functioning like a repeating group: the container’s Message History and DIsplay Messages are updated in real-time, as messages come in. And when you save to your database, that’s best done with the “Message Generation Complete” event (ie., create a workflow that fires when that happens, and update a database record’s Message History and Display Messages with the values in the container, as in the tutorial vid from today). You shouldn’t need to do any “real-time” data loading, per se, as this should be handled automatically.
Hmm… Out of the blue nothing is showing up when I type in an input. But I didn’t change anything. Is anything down on ChatGPT or the server? Is it because the message history is empty? I never looked at the DeBugger when it was working so I’m not sure what to compare it to. Because it literally was just working and now it isn’t.
@launchable Doesn’t work if I reload the page. When “generate” is clicked it no longer turns to “stop generating”. When generate is clicked it just loads for a second then does nothing.
Chrome, on the newest version of the plugin. 5.12.5
But i was on this same thing earlier today and all was working. The ONLY thing that changed between when it was working and when it stopped was me adding a text box and an image box above the repeating group. Then it stopped. Then I CTRL+Z all the way back to when it was working for sure, and it continued to not work.
Great. Also, I think I know where my problem was coming from before regarding not being able to click on the saved conversations and change the screen. At 32:44, you start going over “custom states”.
You click the right group and create a custom state called “Selected Conversation”. And then you found it under “custom state” in the workflow. That was not there for me when I did the same thing. There was no selection available in the dropdown. In my screenshot there is, because that was only AFTER I clicked “Create a new custom state” in that drop down.
For example, I just went and clicked on the right-side group and created a new state called “conversation123” with type text. And I went to the workflow and as you can see it is NOT showing in the dropdown. But yours did.
I don’t know if this is the cause of it, but that’s where both of our apps aren’t aligned.
ah. So that could have been an editing mistake. I initially put the custom state on the wrapper group, but had meant to put it on the page. So I tried to cut the video to skip the mistake. But I may have left it in, or left out both parts
Brilliant plugin, great work! I’m on the latest version 5.12.5, it’s working great! iMac, Chrome. I’m not using chat history though, just one call at a time.
Error handling and testing
It seems like the only way to check if there are errors is by referencing the previous action step (e.g. “ChatGPT send message w/server” and using a condition “Result of that step’s ‘Error’ is empty/Not-empty”.
I’ve created workflows to continue after the Message step for these Error Yes/No conditions. I haven’t had a naturally occurring error happen yet, so I tried to ‘force’ errors by:
Writing a random string for the API key
Disconnecting the socket before doing the stream GPT action
removing the ‘connection info’ dynamic field from the GPT element
All of these caused errors and stopped it from working, but:
gave no error response, popup or show in the bubble debugger
did not give “error not empty” from the Send Message action
and did not get picked up by bubble workflows such as ‘when an unhandled error occurs’ or ‘when element has error running on workflow’.
This means in my app users are ‘hanging there’ having no idea what’s going on, and it looks to me like errors aren’t being reported by the Message action step. Basically I can’t handle errors at all.
Is this possible to improve? Ideally I’d love it if that “error is not empty” condition is 100% reliable and the Message w/server action always displays some kind of error in that output if ANY possible thing goes wrong, and streaming will not happen.
Is there any issue with running the Send Message w/server action and then immediately in the next action step having the condition ‘previous step error is not empty’ condition? I mean how long does the Send Message action wait before moving onto the next step in the workflow, and should it always pickup if there is an error? (it wont just skip past this but then produce an error later that the workflow “missed”?) - i hope that’s clear sorry!
First off, thanks very much for the feedback! It’s super helpful and appreciated.
Second, once I"ve got the Safari/Mac/iOS issue ironed out, the next set of improvements will all be error-handling related. Things like clearer error messages, (ideally) much less frequent errors, and more robust error-recovery. You’re definitely not the only one feeling some pain there. Currently the only error explicitly returned is if an invalid API key is provided. That will trigger an event. As part of the coming updates, I’ll include as many explicit error-handling events as possible.
Third, there shouldn’t be any issue with your setup as per step 2, at least in theory. If I understand you correctly, that’s the intended setup, and then the “Fallback” action would be setup to fire when an error does come back. But if error messages aren’t being returned correctly (which, as you’ve correctly pointed out), they’re not always, this setup will break down. So the issue is probably not with your setup, but with how the plugin is handling some error that you or your users might be seeing. That being said, some uncaught errors (uncaught at the level of the plugin’s actions) do still show up in the developer console, so if you’re familiar with this, and are seeing issues, doesn’t hurt to pop that open and take a look. But it’s not always helpful.
Thanks again for the input! I’m hoping to have an update out Friday that will tidy up some of these bits, and will cc you here on release.