Luis
BBuildShip
•Created by Luis on 3/13/2025 in #❓・buildship-help
Output is not a string: Post-mortem of a bug in which we didn't get any support
Today I reported bug #238909, I didn't get any support and my app was broken because of this bug.
Case:
I have an API Call shipped one month ago and never changed after that. Today it stopped working, meaning that my users couldn't use my app.
It looks like BuildShip did an update that corrupted my API Call shipped to production and all the manual copies I had done. Actually, if I duplicate a flow now, the copy misses a lot of fields so it's not functional.
The automatic backup versions didn't work either because of the update. After loosing most of my day working on it, I found out that I just needed to set the Output of my flow as 'object' instead of 'string'. It was a very simple change but it took me hours to find it. That was something I didn't need to do when I shipped my flow, integrated it in my app, tested my app, and released it to production.
It's a big issue. I rely on BuildShip, but I can not trust it because shipped flows change and stop working without any previous warning.
I'm launching my app, fighting to get tracktion. Every user is key to me and the future of my business. I can not afford my app to stop working so many hours.
I can not spend so much time debugging something that was working.
It's great that BuildShip evolves and it's updated. I understand that I may need to update my flow settings to fit the new BuildShip updates when I modify my flow. I may understand if I receive a warning telling me that I have a period of time to update my app if that's required. I can't accept that my shipped flows change and stop working like that. I can't accept that I have flows saved that miss data when I go back to them. That's not the first time that happens.
7 replies
BBuildShip
•Created by Luis on 2/4/2025 in #❓・buildship-help
The default Firebase app already exists
I have the following Flow:
1. Inputs
2. Switch based on one of the inputs
2.1. Condition 1: 'Execute BuildShip Workflow' pointing to a 2nd Flow
2.2. Fallback
3. Flow Output
The first time I execute it, the Flow Output returns the 2nd Flow output as expected.
After that, the 2nd Flow fails and its Firestore Collection Query node returns: "The default Firebase app already exists. This means you called initializeApp() more than once without providing an app name as the second argument. In most cases, you only need to call initializeApp() once. But if you do want to initialize multiple apps, pass a second argument to initializeApp() to give each app a unique name."
I tried adding a BuildShip Workflow Trigger to the 2nd Flow but now I think it's unnecessary since both flows are in the same workflow.
I found out that's a Firestore issue. There's plenty of documentation about how to solve it when you have your own code, but I don't know how to solve it from BuildShip.
I miss there's no BuildShip documentation about the Execute BuildShip Workflow node.
#firestoreIssue #ExecuteBuildShipWorkflowNodeIssue
7 replies