Skip to content

Certify native configured-ceiling fit and resource ownership #72

Open

Description

@aram356

Acceptance Criteria

  • Bind actual runner settings, native ingress/decoder ownership and operator ceiling/population provenance to native claims, keeping boot and strict acceptance term-for-term equal; do not wait for Cloudflare or hosted Spin facts.
  • Prove applicable headroom and failure/overload/recovery controls; a 4-GiB arithmetic declaration is not an OS-enforced quota or production qualification.

Blocking And Review Gates

  • Blocked by: #46, #47, #48, #50.
  • External blockers: Applicable native SDK/decoder ownership and operator-enforced ceiling/population facts, as enumerated by #50.
  • Conditionally blocks: #91, #99, #100 when their selected path is native.

Use native blocked-by/blocking links for unconditional issue relationships. Conditional target gates are not universal blockers; link only the selected applicable path after its contract is frozen.

Shared Acceptance Requirements

Every implementation issue ships its own unit/conformance, failure, resource and privacy tests. A later integration issue does not postpone those checks. New untrusted decoders include generated hostile-input controls; changed hot paths include repeatable measurements. Use the existing engine, host services, validated config/push path and EdgeZero handler registration. Preserve privacy, authorization, cookie integrity, HTTPS/SSRF protections, deadlines, exact sent coverage, authoritative bidder/alias attribution and bounded work/storage. Standalone and embedded behavior share policy rather than fork implementations.

No issue may claim a missing capability from metadata import, compilation, observed allocations, a signed cookie, or a different artifact's old evidence. New public/configuration behavior requires its reviewed design before execution. No workload reduction, raised ceiling or replacement budget equation is implied. Bodies and evidence must not publish credentials, identifiers, raw consent, private provider addresses or customer configuration.

Technical Ownership

Sources: M7-R0 design/plan, ISSUES.md resource rows and schema qualification record.

Approved Integration Contract

PR #152 merged the specification and delivery plan at 9b83deaa680ad8e867169db3b4ebb195b8a1b33c. Their shared requirements apply: whole-catalog reports with verified skipped: not_implemented rows, positive qualification of every implemented identity/alias on all four adapters, existing build discovery and the qualified common native_only retirement. The first Trusted Server host remains Fastly display; Trusted Server #1505 coordinates host-owned work. The planning merge is not implementation or qualification evidence and changes no workload limit, resource ceiling or configuration mechanism.

Discovered Catalog Acceptance

  • Bind the actual Axum artifact, SDK/features/configuration and configured-ceiling ownership to every discovered implemented identity/alias. Reconcile the exact full catalog with explicit unimplemented skips, independently from exact positive serving coverage.
  • Drive all implemented identities across deterministic within-limit batches, with invalid input, privacy, errors, original deadlines, cancellation and concurrency/one-over refusal controls. Do not widen limits or claim another adapter's receipt as Axum evidence.

Source Contracts

Resource Proof Responsibilities

Responsible roles: the deployment operator supplies enforced quota, memory scope and actual runner settings; Axum SDK maintainers supply ingress, allocator and decoder contracts; Auctioneer Axum qualification maintainers own the application correspondence proof.

Next verification action: bind the existing finite pre-parser connection gate, request-head/body storage, prepared contexts, tasks/channels, completed queues, receipts and teardown overlap to actual enforced populations and the configured memory scope. Reuse published SDK components while independently validating source/toolchain/allocator and the actual application artifact. An unknown operator/provider fact cannot hide overflow of the known configured ceiling.

Source: approved shared resource ownership contract, delivered for review in #162. This records responsibility and the next verification action, not completed proof, target qualification, changed workload limits or permission to close this issue.

Shared Outbound Client And Retained Pool

The default SDK Axum service constructs a shared outbound transport and clones the client into requests. The SDK builder leaves locked reqwest 0.13.4 defaults for idle pooling unchanged: a 90-second idle timeout and usize::MAX idle connections per host. Retained idle-host/connection populations, resolver/TLS/client state and pool-maintenance work can survive completed requests. A finite active call/stream population or an idle timeout does not independently certify their maximum retained storage.

Responsible verification roles: Axum SDK maintainers document those transport owners and lifetimes; the deployment operator supplies actual client/pool overrides, if any; Auctioneer native qualification maintainers independently bound retained host/connection populations and map client, connector, pool, maintenance and socket storage into the existing funded ownership model. Include endpoint/configuration history, completion, cancellation, idle eviction and final client teardown. Do not infer a missing reserve merely from this gap or change pool settings, ceilings or workload without review.

Source: pinned SDK service owner and transport builder. The service owner is byte-identical to the earlier 598f0a2a baseline; the outbound delta changes timer anchoring rather than client construction or pooling. The shared-client and locked reqwest pooling facts above therefore remain unchanged at a7d7fd0. This rebinds the observations, not a physical certificate. #50 records the correspondence; this issue retains actual native certification and remains open.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions