Possible bug on choosing multiple rows + an Action

Questions
,
#1

This is on the back of a issue a client indentified with their App. Seems a strange way for Appsheet do it, but let me explain the issue anyway.

So I have a table where you can click the tick box to choose multiple rows. Then you can choose an action that runs on all those rows. My assumption was it would do each row in turn, but it doesn’t.

As a test I created a grouped action that simply writes “test” into a cell then clears it. So I used the tick box to select 3 rows and ran the action. The sequence I expected to see in Google Sheets was:

BLANK
BLANK
BLANK

Test
BLANK
BLANK

BLANK
BLANK
BLANK

BLANK
Test
BLANK

BLANK
BLANK
BLANK

BLANK
BLANK
Test

BLANK
BLANK
BLANK

But what actually happens is:

BLANK
BLANK
BLANK

Test
BLANK
BLANK

Test
Test
BLANK

Test
Test
Test

BLANK
Test
Test

BLANK
BLANK
Test

BLANK
BLANK
BLANK

This causes mayhem because the real action uses the change from BLANK to Test create a ton of new rows in a different table. But importantly with a reference value from this table that calls the action. So my client chose 24 rows and ran the action. With the result we now have 4000+ rows all referenced to the first row.

Is this by design? Am I doing it wrong? Or is this a bug? Since it would seem logical to me to fully complete the sequence within each action before going on to the next row.

Simon@1minManager.com

Action chain sequencing is failing
#2

Please post screenshots of the configurations of the involved actions.

2 Likes
#3

Hi @Steve I dont see the point of that as its massively convulted and involves 10-20 actions, 5-6 slices and 4 tables. Hence the simplified example above. When we go into a record and click the action button it works fine. But the App is so slow it takes 5-10 mins per row for it to calcuate and create the records in the other table. So quite rightly the user thought it best to use the table tick box to choose 20ish record and let it run over night.

To put the speed of the app in context, the simple test squence above takes 2-3 mins to do the 7 seperate sync items above!

#4

Yikes! Someone’s going to have to look at your app. Consider engaging support@appsheet.com/

1 Like
#5

Tried, but since google took over, the remote response I’ve got has been quite slow and sometimes almost pointless. For example I’ve written a very detailed description and all I get in return is someone directing me to try something on a sample App :triumph: Another was passed through 3 seperate techs before I gave up responding to emails

1 Like
#6

The question still stands though - is this a bug or expected behaviour?

#7

It’s not the behavior I’d expect for a trivial example, but given the complexity of your circumstance, I can’t say whether you should expect it or not.

Consider creating a simple app to recreate the problem in the simplest possible case: a grouped action that sets and unsets a column that’s run across a set of rows. If that simple app demonstrates the odd behavior, you can report a legitimate bug and provide a simple demo app (which developers love!). If it doesn’t demonstrate the odd behavior, it suggests the problem is in the complexity of your app rather than with AppSheet itself.

1 Like
#8

Unfortunately, I understand. :frowning:

1 Like
#9

But the Action I’ve created is simply 2 column change actions grouped together. How more simple can I make it? The sync number changes as the spreadsheet cell updates

When I press the button it clearly shows 6 changes to be synced. Which we all know get processed in chronological order. Because if you get one sync issue then everything stacks up behine that.

#10

I am told by a senior developer:

… actions are run in bulk if given batches of rows. If the action is a sequence it will run each step against the whole batch.

and:

In general I would recommend to avoid relying on logic that depends on the intermediate state of a sequence of actions. The intermediate state is somewhat incidental.

This is news to me, and really makes any complex logic within action sequences unreliable. The result is nondeterministic. For instance, none of my looping-with-actions examples can be trusted.

@Grant_Stead @MultiTech_Visions @LeventK @GreenFlux @tsuji_koichi

5 Likes
#11

Interesting.

#12

I can’t image a single reason why anyone would want them run in batch mode. Its makes no sense. It doesn’t even take less steps. As you said @Steve, we’ve all just realised now we have huge numbers of actions that will not work if the user ticks mutliple rows.

Is this something we can flag as a bug? Can it be changed?

Going foward the only quick fix I can think of is to show the actions as inline and let the user click them that way. But the App is slow that clicking an action normally locks the browser window for 20-30secs :frowning:

#13

@Steve could you elaborate, or get clarification for me; is it:

  1. ref actions run in bulk; or
  2. “bulk actions” run in bulk.

When I say “in bulk” I mean (there is no particular order in which these rows can/should be process, parallel processing can be implemented for speed, etc.).

So are we talking about the “select a bunch of rows, then tap an action button” (aka “bulk actions”) - or are we talking about reference actions?

Also:

Clearly talking about a composite action running… but HOW is this hypothetical action being run? Bulk select or reference action?

And one more thing:

  • is the engineer saying that if I pass 5 records to the system, and enact a composite action;
    • are they saying that instead of each record being processed with the complete composite action stack, instead each stack-step is individually enacted upon each record before moving on to the next.

That last one’s got me all kinds of twisted - I hope that’s not how it works.

1 Like
#14

I believe they perform in the same way, in parallel.

EDIT: I re-read everything and saw that I slightly misunderstood. The italicized text below is not something I’ve confirmed as acting differently than what the engineer said to Steve. I can only confirm that actions in a Group always run in order, regardless of how they may be spread out when being bulk-ran.

Imagine you have a 2-step Grouped Action per record, and you select 5 records to run this on. Each record will do the 2 steps in the appropriate order, but all 5 records will be run in parallel, NOT one after another.

At least this is my experience.

There was an earlier thread on this, I’ll try to find it in a bit.
EDIT:

I encountered this situation trying to do a multi-step math calculation where each step depended on the result of the previous. The “steps” were not individual actions in a Group, but different records. My initial attempt was to use reference actions, under the same assumption that it seems like everyone else has, that it would run in order. It did not.

To fix this, I set it up the action chain to jump back and forth between different Groups via a reference action running on a single item in a list. Similar to how Steve had set up his looping actions examples.

I think your examples are safe, due to what I said above.

Parallel processing is faster?

2 Likes
#15

My experience as well, though that comment from the engineer has me rethinking… could just be my misunderstanding though. (Most likely :rofl: )

1 Like

Company

Platform

Pricing

Solutions

Support

Account

Built in Seattle, WA | Copyright 2019