Simple Trigger: Event Queue limitation?

[Thomas P.]

While I haven't yet ever had any troubles, then I fear I might be about to shoot myself in the foot.

Google's Documentation, for the Simple onEdit-Trigger: https://developers.google.com/apps-script/guides/triggers#onedite 

States: Note:: The onEdit() trigger only queues up to 2 trigger events.

Given that changes to cells made from code in GAS, generally do not cause any event to be fired, then:
Question: Is that "2 trigger events"-queue warning, a form of hard appeal to constrain a user's activity?
- Or, What's the "only queues up to 2 trigger events" about?

[Keith Andersen]

Grok Ai says ...

The "only queues up to 2 trigger events" note in Google's documentation for the `onEdit()` trigger in Google Apps Script (GAS) is not a hard constraint on user activity but rather a technical limitation of how the `onEdit()` simple trigger processes events. Let’s break it down:

### What It Means

The `onEdit()` trigger is a simple trigger that fires automatically when a user manually edits a cell in a Google Sheet. The note about "queues up to 2 trigger events" refers to how Google Apps Script handles rapid, successive manual edits made by a user. Specifically:

- **Event Queueing**: If a user makes multiple edits in quick succession (e.g., typing values into multiple cells rapidly), the `onEdit()` trigger doesn't fire separately for each edit immediately. Instead, it queues up to two of these edit events to process them sequentially.

- **Limit of 2**: The system only keeps up to two pending `onEdit()` events in the queue at a time. If additional edits occur while the queue already has two events waiting, those additional edits may be ignored, and their corresponding `onEdit()` triggers won't fire.

This is a design choice to prevent overwhelming the Apps Script runtime with too many simultaneous trigger executions, which could lead to performance issues or exceed execution time limits.

### Why This Limitation Exists

- **Performance Optimization**: Simple triggers like `onEdit()` are meant to be lightweight and fast. Processing every single edit in real-time for rapid changes could bog down the system, especially in complex scripts or busy spreadsheets.

- **Rate Limiting**: Google Apps Script imposes various quotas and limitations to ensure fair resource usage. The queue limit of two events helps manage server load and prevents scripts from running excessively.

- **Encouraging Best Practices**: The limitation indirectly encourages developers to write efficient code or use alternative approaches (like installable triggers or batch processing) for scenarios involving frequent edits.

### Is It a Constraint on User Activity?

Not directly. The limitation doesn't restrict how many times a user can edit a spreadsheet or what they can do in it. Instead, it affects how many `onEdit()` trigger executions are processed when edits happen in quick succession. For example:

- If a user edits cell A1, then A2, then A3 in rapid succession, the `onEdit()` function might only process the first two edits (A1 and A2) and skip A3 if the queue is full.

- This doesn't prevent the user from making those edits; it just means the script won't respond to every single edit beyond the queue limit.

### Implications for Your Code

Since you mentioned that changes made programmatically (via GAS) don't trigger `onEdit()` (which is correct, as only manual user edits trigger it), this limitation is primarily relevant for scenarios where users are manually editing the spreadsheet rapidly. Here’s what you should consider:

- **Normal Usage**: For typical user interactions (e.g., editing one cell at a time with pauses), this limitation is unlikely to affect your script.

- **Rapid Edits**: If your use case involves users making many manual edits in a short time (e.g., pasting data or quickly typing in multiple cells), some `onEdit()` triggers might not fire.

- **Workarounds**:

  - **Batch Processing**: If you need to handle multiple edits, consider using an installable `onEdit` trigger (set up via script or the Apps Script dashboard), which can be more flexible but still has quotas.

  - **Time-Based Triggers**: For scenarios where you need to process changes in bulk, use a time-based trigger to periodically check the sheet for updates.

  - **Event Object Analysis**: In your `onEdit(e)` function, use the event object (`e`) to inspect the range or value edited and handle multiple changes efficiently within a single trigger execution.

### Example Scenario

Suppose you have this `onEdit()` function:

```javascript

function onEdit(e) {

  var range = e.range;

  Logger.log("Edited cell: " + range.getA1Notation());

}

```

If a user edits cells A1, A2, and A3 in rapid succession:

- The system queues the A1 and A2 edits.

- If the script is still processing A1 when A3 is edited, A3’s event might be dropped.

- Your log would only show edits for A1 and A2.

### Practical Advice

- **Test Your Use Case**: If you’re worried about “shooting yourself in the foot,” test your script with rapid manual edits to see if the queue limitation impacts your functionality.

- **Use Installable Triggers for Complex Needs**: If you need more robust handling of edits, set up an installable `onEdit` trigger, which has fewer restrictions but requires permission setup.

- **Monitor Quotas**: Keep an eye on Apps Script quotas (e.g., execution time limits) to ensure your script doesn’t hit other constraints.

- **Log and Debug**: Add logging to your `onEdit()` function to track which edits are being processed and identify if any are missed.

### Conclusion

The “queues up to 2 trigger events” note is a technical limitation of the `onEdit()` simple trigger to manage performance, not a deliberate restriction on user activity. It’s about ensuring the system can handle rapid edits without overloading. For most use cases, this won’t be an issue, but if you anticipate frequent manual edits, consider optimizing your script or using alternative trigger types to handle your needs robustly.

If you have a specific script or use case in mind, feel free to share it, and I can help analyze whether this limitation might affect you or suggest optimizations!

My website: https://sites.google.com/view/klaweb/
Passions: God, Family, Scriptures, Learning, Data Management, Google Sheets + App Script and much more!

--
You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-apps-script-community/bed46a19-adee-4b5c-b7a4-24f3d0f137dfn%40googlegroups.com.

[Thomas P.]

FYI: Spam Report against Keith Andersen, has been filed.

[Keith Andersen]

Why was a spam report filled?

My website: https://sites.google.com/view/klaweb/
Passions: God, Family, Scriptures, Learning, Data Management, Google Sheets + App Script and much more!

On Sat, Oct 18, 2025, 1:45 PM Thomas P. <thomas....@gmail.com> wrote:

FYI: Spam Report against Keith Andersen, has been filed.

--

You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/google-apps-script-community/582817c9-2d34-49d8-8cbb-be0f344ee65fn%40googlegroups.com.

[Keith Andersen]

Thomas,

Spam complaint for offering you valid information about your query?

If you're man enough to file a Spam complaint, can you be man enough to address me directly as to the reasons you filed a complaint against me?

I think that's only fair.

My website: https://sites.google.com/view/klaweb/
Passions: God, Family, Scriptures, Learning, Data Management, Google Sheets + App Script and much more!

[Keith Andersen]

Will a moderator please address this thread / spam complaint?

My website: https://sites.google.com/view/klaweb/
Passions: God, Family, Scriptures, Learning, Data Management, Google Sheets + App Script and much more!

[Kaushal Practice]

1️⃣ Installable Trigger Example (for heavy tasks)

Normal onEdit(e) triggers have limits — only 2 can queue.

But installable triggers can handle heavier work safely.

Example code:

function myOnEdit(e) {

  // This handles heavy tasks safely

  const sheet = e.source.getActiveSheet();

  const range = e.range;

  // Example: when column A changes, log it in another sheet

  if (range.getColumn() === 1) {

    const logSheet = e.source.getSheetByName("Log");

    logSheet.appendRow([new Date(), range.getValue()]);

  }

}

Now create the installable trigger by running this once:

function createTrigger() {

  ScriptApp.newTrigger("myOnEdit")

    .forSpreadsheet(SpreadsheetApp.getActiveSpreadsheet())

    .onEdit()

    .create();

}

✅ This trigger:

Has full access permissions

Doesn’t suffer from the 2-trigger queue limit

Runs even for heavier or slower operations

---

⚙️ 2️⃣ Batch System Example (for very frequent edits)

Instead of doing heavy work on every edit,

you just mark a signal (like a timestamp),

and a time-driven trigger processes everything in batches.

Example code:

function onEdit(e) {

  const sheet = e.source.getSheetByName("Data");

  // Just mark that an edit happened

  sheet.getRange("Z1").setValue(new Date());

}

Then create a time-based trigger to run every minute (or 5 minutes):

function processBatch() {

  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("Data");

  const signal = sheet.getRange("Z1").getValue();

  if (signal) {

    // Heavy processing happens here

    const data = sheet.getRange("A1:D100").getValues();

    Logger.log("Processed batch at " + new Date());

    // Reset signal

    sheet.getRange("Z1").setValue("");

  }

}

✅ This way:

onEdit() stays fast and lightweight

Heavy work runs safely later

No trigger queue limit problems

---

🧠 Summary Table

Approach When to Use Queue Safe? Notes

Normal onEdit() Small/quick tasks ❌ Keep it very light

Installable Trigger Medium or heavy tasks ✅ Use createTrigger() once

Batch System Frequent or large edits ✅ Safest for high load

---

Would you like me to make a real example (ready-to-use) based on your actual Google Sheet use case — like attendance or data logging?

Kaushal Singh Thkaur MIS, Shankara Hyundai PVT LTD  6262000591  kaushal...@gmail.com Address: Ring Road No. 1, near Maa Kali Mandir, opp. Walfort City, Bhatagaon, Raipur, Chhattisgarh 492001

On Sun, 19 Oct, 2025, 12:15 am Thomas P., <thomas....@gmail.com> wrote:

FYI: Spam Report against Keith Andersen, has been filed.

--

[Thomas P.]

Kaushal,

Thanks! - and, I've also given this some thought after I created this thread, and have some additional smallish questions.

Questions:
I already have an onChange Installable Trigger - because, given my scenario, it was unavoidable to have one such.
The Event-object passed to that Installable onChange Trigger, also pamper for detecting an edit-event - like: if(eventObject.changeType === "EDIT"){...}; 
Now, if I additionally also introduce an onEdit Installable Trigger, then:
- I assume that both Installed Triggers get invoked, but: Am I correct?
    If Yes, then: 

   - Are they invoked in random order, or does one take precedence/priority over the other?
   - Actually, If there's one event-queue pr. trigger, then both may be running in parallel! ; If so, then the Lock Service may be needed :-|
- What if furthermore also adding a Simple onEdit Trigger? (yeah, that'd make a total of 3 Edit-traps)
  Because, as you note: A Simple onEdit-trigger "stays fast and lightweight".

Bonus Question:
If the queue for a simple onEdit-trigger "overflows" (could easily happen, since queue is only 2 long), then:
- Are excess event(s) silently discarded, or is an exception thrown?

[Keith Andersen]

Thomas,

Sorry Grok's solution 'triggered' you....lol, get the pun. Ironically, both Grok and Kaushal gave the same answer, one admittedly more exhausted than the other. Knowledge is a good thing.

Advice: Don't be afraid to use Grok or Claude with respect to technical questions regarding coding. They are incredibly valuable tools that have helped me through some very complex problems on many occasions. I have learned incredibly from their tutelage.

I offered and AI solution for a dual purpose. 1) because it gave accurate information regarding your problem and multiple solutions along with advice on future coding. 2) you apparently had not thought about accessing the amazing knowledge behind AI coding. This was an attempt to expose you to its amazing knowledge. 

But in all things you have a choice and it was meant nothing more than to give you more choices to think about.

What I didn't appreciate was your choice to complain about me trying to help you rather than have dialogue. 

I have offered my help dozens and dozens of people on this form over the years... never once having anyone complain about it... especially for having given accurate information.

You have a choice now to withdraw your spam complaint which I implore you to do so especially having had a few days to think about it. 

Regards,

Keith 

My website: https://sites.google.com/view/klaweb/
Passions: God, Family, Scriptures, Learning, Data Management, Google Sheets + App Script and much more!

To view this discussion visit https://groups.google.com/d/msgid/google-apps-script-community/01185255-1288-4526-8ef7-b093b97a45a2n%40googlegroups.com.