# Pathrule Pattern: Google Cloud Run (1.0.0) # ::pathrule:package:google-cloud-run ### [RULE] Keep request state local and shared clients concurrency-safe (path: /src) A container instance can serve more than one request at a time. Module globals and singleton objects therefore persist across users and can be read or mutated concurrently. - Store actor, tenant, locale, payload, and transaction state in request-local values or explicit context. - Reuse network clients only when their libraries support concurrent use and their connection pools fit maximum instance concurrency. - Do not cache authorization decisions or user data globally without identity keys, expiry, invalidation, and memory bounds. - Load-test the configured concurrency with realistic CPU, memory, database, and outbound-call behavior before increasing it. See /infra/cloud-run for the adjacent decision or procedure that completes this constraint. --- ### [RULE] Finish required work before the request ends or move it to a durable job (path: /src) The platform owns instance lifetime and request-linked resource allocation. Work started after the response can be paused or terminated without completion evidence. - Await work required for the response and honor request cancellation and deadline through downstream calls. - For asynchronous effects, write a durable command or outbox before returning and process it through a retryable service or queue. - Use Cloud Run jobs for finite batch work with explicit input, idempotency, completion, and retry semantics rather than inventing a never-ending HTTP process. - Keep temporary files within instance limits and copy durable results to an external store before reporting success. See /ops/runbooks for the adjacent decision or procedure that completes this constraint. --- ### [MEMORY] Concurrency and instance count form one dependency budget (path: /infra/cloud-run) A service configured for many concurrent requests per instance may use fewer containers but more simultaneous database or API operations in each process. Maximum instances multiplies that demand. - Measure CPU, memory, latency, connection use, and blocking behavior across increasing per-instance concurrency. - Multiply the chosen concurrency and client pool limits by maximum instances and deployment overlap against downstream capacity. - Use minimum instances only for justified latency or availability goals and include their steady cost in the service decision. - Cap maximum instances where databases, third-party APIs, subnet connectors, or quotas are the binding constraint and apply application backpressure too. See /src for the rule or workflow that puts this decision into practice. --- ### [MEMORY] A revision is immutable configuration plus image (path: /infra/cloud-run) Changing configuration creates behavior as surely as changing code. Mutable image tags or console edits make rollback and traffic comparison unreliable. - Reference an immutable image and preserve source revision, build provenance, and schema compatibility with the release. - Version CPU, memory, concurrency, timeout, execution environment, service account, ingress, egress, environment, and secret references in infrastructure code. - Grant the runtime service account only application permissions and keep deployer permissions outside the container. - Compare live revision configuration and image identity with the intended release before moving all traffic. See /ops/runbooks for the rule or workflow that puts this decision into practice. --- ### [SKILL] verify-cloud-run-revision (path: /) --- name: verify-cloud-run-revision description: Deploy or revise a Google Cloud Run service safely. --- # Verify Cloud Run Revision Run this procedure when the affected surface changes, before the result is promoted to production. Record evidence for every step instead of accepting a plausible-looking result. 1. Resolve the immutable image and effective revision configuration, including identity, ingress, egress, secrets, resources, concurrency, timeout, and scaling. 2. Send a small traffic share and verify cold start, readiness, authentication, required network access, denied permissions, and structured logs. 3. Load the revision to configured concurrency while watching latency, CPU, memory, instances, database pools, outbound limits, and request cancellations. 4. Terminate instances and fail dependencies during requests and queued work; confirm required effects are durable and temporary filesystem loss is harmless. 5. Increase traffic only while acceptance signals hold, and route back to the prior revision immediately if errors, latency, or capacity regress. ## Exit criteria The change is complete only when the expected behavior, failure behavior, and rollback path have all been exercised with representative data. Preserve the evidence with the change so the next operator can repeat the same checks.