When Two Triggers Write at Once, Your Gemini Result Quietly Vanishes — A Durable Result Store for Apps Script

Wrap the critical section in LockService

The index update is a read-modify-write, so serialize it. Apps Script's LockService offers three locks; pick by the scope you need to protect.

Time-driven triggers usually run as the script owner, so getScriptLock is the natural choice when you want to stop triggers from colliding with each other. The key is the waitLock budget — it throws if the lock cannot be acquired in time.

function withScriptLock_(fn) {
  const lock = LockService.getScriptLock();
  try {
    lock.waitLock(25 * 1000);  // wait only 25s, leaving room in the 6-min budget
  } catch (e) {
    throw new Error('lock_timeout'); // let the caller decide to retry
  }
  try {
    return fn();
  } finally {
    lock.releaseLock();  // always release, even on error
  }
}

If you get greedy and set waitLock close to six minutes, lock-waiting alone eats the execution budget and leaves no time for the actual Gemini call or the write. I keep the critical section to "reading and writing the index only," and do the Gemini call and the Drive write outside the lock. Keeping heavy I/O out of the lock is the surest way to avoid a pile-up of waiters.

Offload large output to Drive

The result body goes to a durable sink, not PropertiesService. Here I use a Drive text file and overwrite by name so a re-run of the same job does not spawn duplicate files.

const SINK_FOLDER_ID = 'YOUR_DRIVE_FOLDER_ID';
 
function writeSink_(jobId, text) {
  const folder = DriveApp.getFolderById(SINK_FOLDER_ID);
  const name = 'result_' + jobId + '.txt';
  const it = folder.getFilesByName(name);
  if (it.hasNext()) {
    const f = it.next();
    f.setContent(text);       // overwrite the existing one
    return f.getId();
  }
  return folder.createFile(name, text, MimeType.PLAIN_TEXT).getId();
}

To speed up reads, add CacheService as a hot path. But the cache is volatile and disappears within six hours at most, so the source of truth always stays in Drive. The cache only exists to cut how often you go back to Drive.

function readResult(jobId, index) {
  const cache = CacheService.getScriptCache();
  const hot = cache.get('res_' + jobId);
  if (hot) return hot;
 
  const entry = index[jobId];
  if (!entry) return null;
 
  const text = DriveApp.getFileById(entry.fileId).getBlob().getDataAsString();
  if (text.length < 90 * 1024) {          // stay under the 100KB ceiling
    cache.put('res_' + jobId, text, 3600); // hot for one hour
  }
  return text;
}

Stop double-apply with an idempotency key

Triggers fire twice "just in case," or fail and get retried. So the same job saving twice must not change the outcome — give it an idempotency key. A string derived from the input (prompt + model ID + a hash of the source data) is easy to work with.

function idempotencyKey_(prompt, modelId, sourceText) {
  const seed = modelId + '|' + prompt + '|' + sourceText;
  const digest = Utilities.computeDigest(
    Utilities.DigestAlgorithm.SHA_256,
    seed,
    Utilities.Charset.UTF_8
  );
  return digest.map(b => ((b & 0xff) + 0x100).toString(16).slice(1)).join('');
}

On save, if the same jobId already carries the same idempotency key in the index, return the existing fileId without writing. However many times the triggers misbehave, the apply converges to exactly once.

Pull it together: DurableResultStore

Here are the parts assembled into one save function. Notice that the critical section is only "read and write the index," with the Gemini call and the Drive write done outside it.

const INDEX_KEY = 'job_index_v1';
 
function saveResult(jobId, idemKey, text) {
  // do the heavy I/O before taking the lock
  const fileId = writeSink_(jobId, text);
 
  return withScriptLock_(() => {
    const props = PropertiesService.getScriptProperties();
    const index = JSON.parse(props.getProperty(INDEX_KEY) || '{}');
 
    const existing = index[jobId];
    if (existing && existing.idem === idemKey) {
      return existing.fileId;   // idempotent: avoid double-apply
    }
 
    index[jobId] = {
      idem: idemKey,
      fileId: fileId,
      len: text.length,
      at: new Date().toISOString(),
    };
    assertIndexSize_(index);    // reject before touching 500KB
    props.setProperty(INDEX_KEY, JSON.stringify(index));
    return fileId;
  });
}
 
function assertIndexSize_(index) {
  const bytes = Utilities.newBlob(JSON.stringify(index)).getBytes().length;
  if (bytes > 450 * 1024) {     // treat just under 500KB as a warning zone
    throw new Error('index_near_limit:' + bytes); // prune completed jobs
  }
}

Putting writeSink_ outside the lock is deliberate. A Drive write can take a few hundred milliseconds, and holding the lock across it would steal that much execution budget from the waiting trigger. Write the body first, and all that remains inside the lock is a small JSON update that finishes in an instant.

Left alone, the index drifts toward the 500 KB wall. Once a job has completed and been read, drop it from the index while keeping only its body file in Drive, and you stay clear before assertIndexSize_ ever fires. In my own setup at Dolice Labs, a separate small trigger prunes expired entries once a day.

Small judgments that paid off

Even after adding getScriptLock, I initially set waitLock long and saw occasional lock-wait timeouts. Cutting the wait to 25 seconds and evicting heavy I/O from the critical section made the timeouts nearly disappear. The shorter you hold a lock, the better it tolerates contention.

The other one was deriving the idempotency key from the input hash. I also tried minting a unique ID on the trigger side, but retries assigned a fresh ID and the same generation got saved twice. A key determined by the input lands on the same value across retries, so double-apply stops on its own.

One next step

Take a single read-modify-write in your own Apps Script — something like appendResultNaive — and wrap just that one spot in withScriptLock_. Watching a result survive when triggers overlap is the fastest way to feel the change. From there, extend it into a store that offloads the body to Drive, and you remove one more way for an overnight automation to fail in silence.