I’ve got an action that adds a user’s phone number and selected location from a google sheet to a new row on a glide sheet. This started happening January 25th around 9:48 AM.
we have the same problem Double posts...? - #23 by Silvio_Rebelo
1 Like
me too!
1 Like
Yea, this is happening on my most used app. Client is paying 5 figures annually for it. The only people who have noticed are the clerks using the backend. Fingers crossed the admins don’t see it 
It happens to me on my restaurant apps that automatically print orders …
Do you know how many double orders they cooked?
Unfortunately I have to give months of subscription for this issue 
@Jonathon_Kohn Could you share a support link, please, and give more details?
1 Like
https://go.glideapps.com/support/7c257a0f-c8be-443f-957e-6ded1b3e8786
Using the screenshot above (23 duplicate entries) upon 1 action, when my user enters a 10 digit number, above 1000000000 and below 9999999999, they then have access to an “Add row” floating button that add’s that number and the location they selected to a new sheet then clears their user specific number and location. The user specific options, Phone # and location, are done on a google sheet and the “Add row” action sends them both to a glide sheet.
The clerks using the backend to contact each person waiting in line have also reported up to 4 numbers being contacted at once during an action that calls to zapier > twilio. The action is built into an inline list that uses conditions to set date/times for each step of the virtual queue process.
number is submitted > client appears on inline list > click client to send text via Zapier/twilio > click again to mark as “serving” > click again to complete and clear
I think I discovered something that may or may not be related. I mentioned the issue in this thread: Reset Multiple Rows At Once . I sort of fixed it, but that fix only works for the user that adds a task item to the list. What’s happening in my case, is that the action that’s supposed to happen when list item is clicked, is firing when a new row is added. It should only fire when a list item is clicked by the user. To get around it, I have a set column action that clears the column that was inadvertently set, after the add row action, to clear the value that should only be set by clicking on a list item. Somehow, my column value is getting set even though I’m not explicitly setting it. The problem though, is that if another user has the app open and someone else adds a row to the list, it fires that list click action for all users once the new list item pops up on the on the screen.
@Mark I wonder if something similar is happening here, where multiple people have the app open, and when a row is added, an action fires on all user devices that currently have that app open and it adds multiple rows because the action is firing on multiple peoples devices??? Or maybe other users are doing something in their app and it fires the action over and over for the one user that had just added a row??? Not sure if it’s the same issue, but there is definitely a bug with actions being called when not initiated by the user. Could be a nice future feature to automatically active actions without user input, but I’m guessing that’s not the intention here.
2 Likes
That HAS to be related. My app is being used by up to 32 clerks and 50 clients at any given time.
1 Like
1 Like
@Mark
If it helps, these are the two zapier logs of an order that generated 2 rows.
First trigger (THIS IS THE RIGHT ROW)
appID: dga64tnZy2A64e15adLl
params:
Val1:
value: *******
type: string
Val2:
value: *******
type: number
idempotencyKey: oQjNFEsrSu-ZURJvMn9u2Q
hookKind: app-action
timestamp: 2021-02-05T17:47:19.983Z
Fields with no value:
querystring
Second Trigger (THIS IS THE BLANK ROW)
hookKind: app-action
idempotencyKey: J5zgN.iYQ86pitaYrdKzFA
appID: dga64tnZy2A64e15adLl
params:
Val1:
type: string
value: ****
Val2:
type: number
value: ****
timestamp: 2021-02-05T17:47:21.883Z
Fields with no value:
querystring
Also able to confirm, a single “zapier” action is being sent up to 4 times per single action press. I just got 4 error emails from zapier that the number is unable to be texted due to bad area code.
1 Like
No, that’s very unlikely here. The data is probably not shared in the first place, and there’s no way to trigger an action on another device remotely. They are triggered directly by UI interaction.
1 Like
One thing I just discovered is that you can tap the “+” button multiple times in quick success, and it will add multiple rows. That’s because the “Add” action will wait until the row is written to Glide’s backend, and only then will the “Set” action reset the form.
I apologize for submitting a bunch of zero phone numbers 
3 Likes
The clerks have told me they haven’t noticed duplicates when they enter a users info, only when a user enters their own info from the home page.
The timestamps in the image above are all exactly the same. Any idea what’s causing those duplicates?
OK, I think I do see an error in the logic of my app and I would have to agree, that in my case, an action isn’t being triggered remotely, but something still isn’t right. I made a simpler example to show what I’m seeing. If you add a task, you will see in that list description that the ParentID-Selected column gets populated when the task is added to the list. The only time that column should ever be altered is when clicking on the task within the list. Somehow, the Add Row action is firing the Set Column action on that list once the row is added.
Like I wrote above, I can reproduce it by tapping the “+” multiple times quickly. You could add some mechanism to prevent that, but we’ll also think about whether we can prevent that from Glide’s side.
The + you used is not where the problem exists. The + is what the clerks use. They don’t press it more than once.
The people waiting outside are adding themselves, without having to log in, and THAT action is literally adding them up to 23 times to the Glide Sheet with a single action. Why is this all being swept under the rug? This is a huge paying client and the issue has only started a few days ago.
Obviously something was changed behind the scenes… this hasn’t been an issue before now.
Would you be willing to make a duplicate of your without any user data that the rest of us could beat on and maybe see the clerk side of it too?
1 Like