home / skills / trantuananh-17 / product-reviews / cloud-tasks

cloud-tasks skill

/.claude/skills/cloud-tasks

This skill helps you implement Cloud Tasks patterns for background processing with automatic retries and rate limiting across tasks.

npx playbooks add skill trantuananh-17/product-reviews --skill cloud-tasks

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.4 KB
---
name: cloud-tasks-queue
description: Use this skill when the user asks about "Cloud Tasks", "background jobs", "delayed processing", "rate limit handling", "async queue", "enqueue task", or any task queue work. Provides Cloud Tasks patterns for background processing with automatic retries and rate limiting.
---

# Google Cloud Tasks Patterns

## Overview

Cloud Tasks provides reliable, asynchronous task execution with automatic retries, rate limiting, and scheduled delays.

**Cost:** ~$0.40 per million operations (95% cheaper than Firestore queues)

---

## Basic Usage

```javascript
import {enqueueTask} from '../services/cloudTaskService';

// Immediate task
await enqueueTask({
  functionName: 'enqueueSubscriber',
  data: {
    type: 'triggerOrder',
    data: {shopId, orderId, customerId}
  }
});

// With delay (common for webhooks)
await enqueueTask({
  functionName: 'enqueueSubscriber',
  opts: {scheduleDelaySeconds: 3},
  data: {
    type: 'detectSyncTier',
    data: {shop, customer}
  }
});
```

---

## Rate Limit Handling

```javascript
case 'klaviyoSync': {
  const {shopId, customerId, profileData, retryCount = 0} = data;

  const result = await klaviyoService.createOrUpdateProfile(profileData);

  if (result.success === false && result.retryAfter) {
    await enqueueTask({
      functionName: 'enqueueSubscriber',
      data: {
        type: 'klaviyoSync',
        data: {shopId, customerId, profileData, retryCount: retryCount + 1}
      },
      opts: {scheduleDelaySeconds: Math.ceil(result.retryAfter)}
    });
    return; // Don't throw - prevents Cloud Tasks auto-retry
  }
  break;
}
```

---

## Common Delay Values

| Use Case | Delay | Reason |
|----------|-------|--------|
| Order webhook processing | 3s | Wait for Shopify data consistency |
| Tier detection | 3s | Allow points to settle |
| Customer segment update | 5s | Wait for customer creation |
| Rate limit retry | varies | Use `retry-after` header |

---

## Error Handling

| Error Type | Action |
|------------|--------|
| Permanent (no integration) | Return early, don't throw |
| Retriable (network timeout) | Throw for auto retry |
| Rate limit | Re-enqueue with delay |

---

## Checklist

```
□ Use enqueueTask() from cloudTaskService
□ Include task type in data payload
□ Add retry count for rate-limited operations
□ Return early for permanent failures
□ Re-enqueue with delay for rate limits
□ Set max retry count to prevent infinite loops
```

Overview

This skill explains patterns for using Google Cloud Tasks to run background jobs with scheduled delays, automatic retries, and rate limiting. It focuses on practical patterns for enqueuing tasks, handling rate-limit responses, and deciding when to retry versus return early. The goal is reliable asynchronous processing with predictable costs and behavior.

How this skill works

It inspects task payloads that include a task type and data, then enqueues HTTP or function-invocation tasks via a cloudTaskService helper. Tasks can be scheduled with delays, include retry count metadata, and be re-enqueued when integrations return retry-after information. Error semantics guide whether to throw (trigger Cloud Tasks auto-retry), return early (permanent failure), or re-enqueue with a delay (rate limit).

When to use it

  • Process webhooks or background work that must be decoupled from user requests
  • Schedule short delays to wait for eventual consistency (e.g., 3–5s)
  • Handle third-party API rate limits by delaying retries
  • Retry transient network errors automatically using Cloud Tasks
  • Limit throughput with rate limiting rules in task queues

Best practices

  • Always include a task type in the payload so handlers can route logic
  • Add and increment a retryCount to prevent infinite re-enqueue loops
  • For rate-limit responses, re-enqueue with scheduleDelaySeconds using the provider's retry-after header
  • Return early for permanent errors (missing integration) instead of throwing
  • Throw for transient errors to let Cloud Tasks apply its automatic retry policy
  • Set sensible max retry counts and backoff to avoid runaway processing

Example use cases

  • Enqueue order webhook processing with a 3s delay to allow upstream consistency
  • Detect customer tiers after a short delay so points or events settle
  • Retry a failed Klaviyo profile update by re-enqueuing with scheduleDelaySeconds from retry-after
  • Batch low-priority reports or follow-ups to run asynchronously and under rate limits
  • Use enqueueTask() wrapper to centralize queue options and observability

FAQ

How do I decide whether to throw or re-enqueue when an API call fails?

If the failure is transient (network timeout), throw to let Cloud Tasks auto-retry. If the remote API returned a rate-limit with retry-after, re-enqueue with a schedule delay. If the failure is permanent (no integration), return early and do not throw.

What delay values are typical?

Common short delays are 3s for webhook/order consistency and 5s when waiting for entity creation. Use the provider's retry-after value for rate-limit retries.

How do I prevent infinite retries?

Include a retryCount in the payload and stop re-enqueuing once it exceeds a defined max. Also configure queue max attempts and backoff settings in Cloud Tasks where available.