Improve Serverless Runtime

Operation

Implement the selected serverless/edge runtime correction and verify the affected invocation contract. Read serverless runtime boundaries. A prior audit is optional when the user and repository identify the target.

Required input

The selected handler, provider/runtime and compatibility configuration, trigger, success/acknowledgment promise, authoritative effect and retry owner. Identify the concrete invocation state and permitted local/provider environment.

Goal and scope

Complete the selected correction across handler lifetime, response/acknowledgment, state ownership and the directly affected effect. Preserve the existing provider and trigger unless migration is explicitly requested. Do not replace an application's architecture to make a local emulator pass.

Establish the contract

Record the actual runtime/version, trigger, configured limits and product success promise. Reproduce the defect with a concrete event or request. Define what must be durable before response, what may be deferred, how failure is surfaced and which component owns retry. Identify the stable business operation key where duplicate delivery is possible.

Implementation targets

• Await work required for a successful response or acknowledgment. For intentionally deferred work use the provider-supported lifetime mechanism or durable handoff that meets the guarantee. Do not substitute best-effort deferral for promised durable completion.
• Propagate required-work failures so callers or event sources receive the correct outcome. Preserve the provider's batch response contract and avoid acknowledging failed records as successful.
• Keep invocation-specific identity and mutable user state local to the invocation. Reuse safe clients/connections where supported while making temporary/cache state explicitly non-authoritative.
• Deduplicate non-repeatable effects at their actual owner using stable identity and appropriate atomicity. Coordinate retry, visibility/lease and timeout behavior so two invocations cannot bypass the protection.
• Bound fan-out and admission to downstream capacity. Clean up invocation-owned resources on rejection/cancellation without closing legitimately shared clients after every request.
• Use APIs and bindings supported by the deployed runtime and compatibility configuration. Keep preview/testing values from silently becoming production authority.

Change discipline

Apply the fix to the owner rather than adding sleeps, extending arbitrary timeouts or swallowing rejections. Update directly affected trigger/binding configuration, tests and operational documentation. Preserve legitimate normal and retry paths and avoid unrelated provider, dependency or framework upgrades.

Validation

Demonstrate the original failure before the fix and success afterward. For lifetime changes, hold the storage/downstream promise unresolved and prove the response cannot claim completion; then reject it and verify failure propagation. For delivery changes, replay the same identity concurrently and across restart or partial-batch retry, checking durable effect counts. For reuse changes, run sequential invocations with different identities and inspect state isolation.

Run available native/emulator checks and state which cases require the real provider. Report the changed contract, actual results and remaining deployment, quota or disconnect checks. Publish or alter cloud resources only within the user's existing authorization.

Feed the same input identity, required-work boundary and corrected handler/configuration into Serverless Invocation Check. Recheck a failed response/acknowledgement or retained-identity case at its owner, then review the full resulting patch until clean or blocked. Do not turn optional provider experiments into required infrastructure creation.