Iâm in a similar position. I believe in this project and would love to deploy it more widely, but this kind of fragility and unreliability is a wider problem with this otherwise super high potential product.
I believe I understand the issue now. I noticed that the version being used in Google Sheets is 0.7.7 (around 10 months old). At that time, it was polling for new rows every 5 minutes, but this approach was fragile for many use cases (as pointed out by @HoldYourWaffle back then). For example, adding or removing a row could disrupt the flow.
To resolve this, click on the three dots on the trigger, and replace it with Google Sheets again. This will upgrade it to version > 0.10.0, which works in a different way.
We usually auto upgrade the piece when there is minor changes, but since this was fundamental change we canât auto upgrade older version.
I think you should find a way to notify users that they need to update the element on the automation or allow them to see if there is an update.
At the moment there is no way to know if there is update and most time it doeosnât update by itself.
Itâs a big problem when the main goal for the automation is to be stable and in some cases it doesnât give me the options of the new updates (like in smtp that you added the html option and i donât have it in most emails).
How did you implement this? So far I havenât been able to come up with a solution that isnât vulnerable to race conditions.
I agree, this is another big reason why I canât deploy Activepieces more widely yet. The problem is twofold:
We really need a system for migrating piece configurations to newer versions, in the vast majority of cases that should be possible to do fully automatically.²
For the special cases we need a good workflow for managing these updates. For me thatâd include:
Flow browser: mark flows that contain outdated pieces.
Flow editor: mark outdated pieces.
Piece editor: a changelog excerpt/summary, link to relevant documentation if applicable, link to full changelog and an âUpdate pieceâ button. Note that pieces can be multiple versions behind.
An overview of outdated pieces across all flows.
Grouped by piece type + current version, since youâll often have multiple instances of a migration path across flows.
Relevant changelog information, similar to the flow editor.
Bulk operation for force-upgrading piece instances, since not every breaking change requires explicit intervention in every situation. (Like the aforementioned Google Sheets trigger upgrade.) An admin can evaluate this with the changelog.
(Email) notifications when thereâs new updates for pieces in production.
Preferably summarized per a configurable interval.
Edit: itâs worth noting that a âbreaking changeâ isnât necessarily breaking for every instance of that piece. For example, removing an option that a user didnât use shouldnât require manual intervention.
Semver therefore isnât a good indicator, determining that an upgrade requires manual intervention should be the responsibility of the migration script (as in, only require manual intervention if thereâs no way to migrate that piece instanceâs config such that it has identical behavior).
Edit 2 electric boogaloo: probably not a good idea to upgrade pieces unattended, even if itâs a fully transparent migration. Bugs are inevitable, Iâd prefer pressing a couple buttons once a week to flows (silently) breaking in production
