WEB / WEB-21.S03

Resource limits, errors and fail-open boundaries

Keep budgets, permission and partial-failure evidence separate.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Read allowed

Read request ready
The reader has prepared a read request for the public Tea & Bread title. Admission has not evaluated permission, byte budget, concurrency or deadline; no read or write has reached the store.
Reader
Fixed note read request ready
Admission / errors
Admission pending; no reservation/dispatch
Public note store
Own public note unchanged; no read/write
Request reached gate
Admission sees completed request arrival; size, permission, concurrency and deadline are separate conditions.
Reader
Fixed note read request ready
Admission / errors
Read arrived; size/permission/quota/deadline pending
Public note store
Own public note unchanged; no read/write
Admission allowed
Finite size, known permission, available quota and deadline are accepted; a read is prepared after local reservation.
Reader
Fixed note read request ready
Admission / errors
Permission/budget accepted; reserved; read ready
Public note store
Own public note unchanged; no read/write
Approved read arrived
The store records completed approved-read arrival; the selected profile permits only a read-only projection.
Reader
Fixed note read request ready
Admission / errors
Permission/budget accepted; reserved; read ready
Public note store
Approved read received; projection pending
Title projection ready
The store prepares fixed Tea & Bread in a local read-only step; no write is a consequence of this operation’s scope.
Reader
Fixed note read request ready
Admission / errors
Permission/budget accepted; reserved; read ready
Public note store
Tea & Bread title body ready; write=false
Body reached gate
The completed body arrival reaches the gate; reservation cleanup and safe client projection occur in the next local step.
Reader
Fixed note read request ready
Admission / errors
Title body received; cleanup pending
Public note store
Tea & Bread title body ready; write=false
Cleanup and response
The local reservation is released and a public-title response is prepared; this is not a distributed-counter or crash-recovery test.
Reader
Fixed note read request ready
Admission / errors
Reservation released; title response ready
Public note store
Tea & Bread title body ready; write=false
Read result delivery
The reader receives the title at completed response arrival; actual HTTP status, resource isolation and throughput are not established.
Reader
Received title=Tea & Bread; read-only result
Admission / errors
Reservation released; title response ready
Public note store
Tea & Bread title body ready; write=false

Quota full

Read request ready
The reader has prepared a read request for the public Tea & Bread title. Admission has not evaluated permission, byte budget, concurrency or deadline; no read or write has reached the store.
Reader
Fixed note read request ready
Admission / errors
Admission pending; no reservation/dispatch
Public note store
Own public note unchanged; no read/write
Request reached gate
Admission sees completed request arrival; size, permission, concurrency and deadline are separate conditions.
Reader
Fixed note read request ready
Admission / errors
Read arrived; size/permission/quota/deadline pending
Public note store
Own public note unchanged; no read/write
Gate evidence separated
The finite predicate evaluates necessary conditions separately; spare quota cannot allow unknown permission.
Reader
Fixed note read request ready
Admission / errors
Known quota full; no reservation
Public note store
Own public note unchanged; no read/write
Dispatch withheld
Pre-dispatch denial leaves the store untouched; absent body and write follow from this selected state order.
Reader
Fixed note read request ready
Admission / errors
Dispatch=0; delivery=0; body absent; write=false
Public note store
Own public note unchanged; no read/write
Safe error ready
A safe client diagnostic is prepared; no stack dump, secret or internal path enters this response.
Reader
Fixed note read request ready
Admission / errors
Safe error response ready; protected body absent
Public note store
Own public note unchanged; no read/write
Safe error received
The reader sees completed error arrival; pre-dispatch evidence is not confused with a later unknown-commit situation.
Reader
Error received; protected body absent; no read/write
Admission / errors
Safe error response ready; protected body absent
Public note store
Own public note unchanged; no read/write
Evidence scope outcome
The reader interprets the local diagnostic; the general response-lost write scenario remains unknown in a separate ledger.
Reader
No dispatch/delivery/body/write; cause retained
Admission / errors
Safe error response ready; protected body absent
Public note store
Own public note unchanged; no read/write

Permission absent

Read request ready
The reader has prepared a read request for the public Tea & Bread title. Admission has not evaluated permission, byte budget, concurrency or deadline; no read or write has reached the store.
Reader
Fixed note read request ready
Admission / errors
Admission pending; no reservation/dispatch
Public note store
Own public note unchanged; no read/write
Request reached gate
Admission sees completed request arrival; size, permission, concurrency and deadline are separate conditions.
Reader
Fixed note read request ready
Admission / errors
Read arrived; size/permission/quota/deadline pending
Public note store
Own public note unchanged; no read/write
Gate evidence separated
The finite predicate evaluates necessary conditions separately; spare quota cannot allow unknown permission.
Reader
Fixed note read request ready
Admission / errors
Permission evidence unknown; no allow
Public note store
Own public note unchanged; no read/write
Dispatch withheld
Pre-dispatch denial leaves the store untouched; absent body and write follow from this selected state order.
Reader
Fixed note read request ready
Admission / errors
Dispatch=0; delivery=0; body absent; write=false
Public note store
Own public note unchanged; no read/write
Safe error ready
A safe client diagnostic is prepared; no stack dump, secret or internal path enters this response.
Reader
Fixed note read request ready
Admission / errors
Safe error response ready; protected body absent
Public note store
Own public note unchanged; no read/write
Safe error received
The reader sees completed error arrival; pre-dispatch evidence is not confused with a later unknown-commit situation.
Reader
Error received; protected body absent; no read/write
Admission / errors
Safe error response ready; protected body absent
Public note store
Own public note unchanged; no read/write
Evidence scope outcome
The reader interprets the local diagnostic; the general response-lost write scenario remains unknown in a separate ledger.
Reader
No dispatch/delivery/body/write; cause retained
Admission / errors
Safe error response ready; protected body absent
Public note store
Own public note unchanged; no read/write

Deadline reached

Read request ready
The reader has prepared a read request for the public Tea & Bread title. Admission has not evaluated permission, byte budget, concurrency or deadline; no read or write has reached the store.
Reader
Fixed note read request ready
Admission / errors
Admission pending; no reservation/dispatch
Public note store
Own public note unchanged; no read/write
Request reached gate
Admission sees completed request arrival; size, permission, concurrency and deadline are separate conditions.
Reader
Fixed note read request ready
Admission / errors
Read arrived; size/permission/quota/deadline pending
Public note store
Own public note unchanged; no read/write
Gate evidence separated
The finite predicate evaluates necessary conditions separately; spare quota cannot allow unknown permission.
Reader
Fixed note read request ready
Admission / errors
now=deadline; pre-dispatch deadline denied
Public note store
Own public note unchanged; no read/write
Dispatch withheld
Pre-dispatch denial leaves the store untouched; absent body and write follow from this selected state order.
Reader
Fixed note read request ready
Admission / errors
Dispatch=0; delivery=0; body absent; write=false
Public note store
Own public note unchanged; no read/write
Safe error ready
A safe client diagnostic is prepared; no stack dump, secret or internal path enters this response.
Reader
Fixed note read request ready
Admission / errors
Safe error response ready; protected body absent
Public note store
Own public note unchanged; no read/write
Safe error received
The reader sees completed error arrival; pre-dispatch evidence is not confused with a later unknown-commit situation.
Reader
Error received; protected body absent; no read/write
Admission / errors
Safe error response ready; protected body absent
Public note store
Own public note unchanged; no read/write
Evidence scope outcome
The reader interprets the local diagnostic; the general response-lost write scenario remains unknown in a separate ledger.
Reader
No dispatch/delivery/body/write; cause retained
Admission / errors
Safe error response ready; protected body absent
Public note store
Own public note unchanged; no read/write

ACTORS · STATE · DATA FLOW

Quotas and permission do not substitute for each other

Resource policies include separate bounds for request size, concurrency, work budget, deadlines and queues. A rate limit restricts frequency over a time window; it does not by itself bound one expensive operation’s memory use or fan-out. Atlas Notes selects maxConcurrent=2, maxBytes=64 and deadlineTick=10 for a public-title read. These are finite teaching values, not measured production capacity. PermissionKnown and permissionAllowed remain separate from quota admission. A permitted actor cannot start a read when quota is full, and spare capacity cannot open unknown permission. Cheap size/shape checks before expensive work provide a useful boundary, not proof of OS/container isolation. The scene dispatches nothing to the store before completing its gate. Success is a read-only title projection; no write operation or store mutation is modeled.

Deadlines, cancellation and partial failure

A deadline can mean that a caller stops waiting; it does not prove that downstream work stopped or that a side effect was undone. Checking the deadline before admission keeps this model’s expired branch from reaching the store. Losing a response after a write was dispatched is different: its result may be unknown, and a blind retry can repeat the action. The artifact keeps that general partial-failure situation in a separate ledger, without adding false certainty about prior writes to this lesson’s read-only negative cases. Cancellation propagation, transactional commits and idempotency scope need actual system integrations. A local quota reservation is released after either a normal result or an exception. That finally behavior is testable for a local counter; process crashes, distributed leases and autoscaling under load are not verified here.

Error format and the scope of evidence

Error handling gives clients a meaningful status and limited explanation while retaining access-controlled diagnostics on the server. Stack dumps, secrets and internal paths do not enter the client body. RFC9457 supplies bounded problem descriptions for troubleshooting and replaces RFC7807. This ledger uses typed decision codes, not actual HTTP responses. A 429 describes rate limiting, and Retry-After is optional; neither every concurrency rejection being 429 nor a future retry necessarily succeeding follows from that. Unknown permission, known denial, deadline and full quota remain different internal reasons. A simple client message does not require telemetry to collapse every outcome into one error. Track dispatched actions, resource delivery and available commit evidence separately.

The permission boundary of graceful degradation

Keeping part of a system available when a dependency fails can be useful. Turning an unreachable permission service into allow is a different decision. A fail-closed gate withholds the protected action; public help or an offline reference may be offered under another policy. That alternative action is not silently substituted for the original protected body. The missing-permission row retains evidence=null and allow=false. A cached decision requires an explicit actor/object/action scope, freshness and revocation profile; unlimited reuse of an old allow is not graceful degradation. Error boundaries do not convert every exception into uncontrolled success. A resource limit adds an independent admission layer above permission. This finite predicate guarantees neither actual fault tolerance, network availability nor resource isolation.

Read every scenario without motion

Quota/permission

Normal-read admission
19 bytes fit maxBytes 64, active 1 + requested 1 is 2, and permission evidence is true. now 2 precedes deadline 10; these finite gates allow title delivery but no write.
Admission/failure ledger
Normal allowed / public body / no write
Budget and authority gate
Not yet evaluated
Operation outcome
Not yet evaluated
Quota-full is a distinct cause
active 2 + requested 1 exceeds maxConcurrent 2. quota-full has no dispatch or body; a closed budget with valid permission does not mean an unauthorized caller.
Admission/failure ledger
Normal allowed / public body / no write
Budget and authority gate
Quota full / dispatch false / not authz denial
Operation outcome
Not yet evaluated
Unknown-permission gate
permission-missing retains null and closes protected delivery. Known denial false has the same no-body result with different evidence; unknown dependency is not completed into allow.
Admission/failure ledger
Normal allowed / public body / no write
Budget and authority gate
Quota full / dispatch false / not authz denial
Operation outcome
Permission null ≠ false / both withheld
Deadline equality
At now 10 equal to deadlineTick 10, dispatch does not start. Logical equality proves neither network timeout, cancellation nor stopped downstream workers.
Admission/failure ledger
Deadline equality / no dispatch
Budget and authority gate
Quota full / dispatch false / not authz denial
Operation outcome
Permission null ≠ false / both withheld
Concurrency versus rate
maxConcurrent budgets simultaneously active work. rateLimitWindowDefined is false; this is not universally HTTP429 or mandatory Retry-After behavior.
Admission/failure ledger
Deadline equality / no dispatch
Budget and authority gate
Concurrency budget / no rate-window claim
Operation outcome
Permission null ≠ false / both withheld
Pre-dispatch scope
Untouched-store conclusions for these denials depend on explicit no-dispatch ordering. Finite integer gates prove neither overload capacity nor distributed counters or isolation.
Admission/failure ledger
Deadline equality / no dispatch
Budget and authority gate
Concurrency budget / no rate-window claim
Operation outcome
Known pre-dispatch denial / no downstream mutation

Partial outcome

Lost-response context
The lost-response ledger has dispatch true with null commit evidence and write outcome. actualWritePerformed is false; it illustrates evidence bounds rather than executing a write.
Admission/failure ledger
Dispatch true / commit unknown
Budget and authority gate
Not yet evaluated
Operation outcome
Not yet evaluated
Error is not rollback
Caller error does not prove downstream rollback. Known pre-dispatch denial may have false commit, while a dispatched unknown cannot be reduced to that boolean.
Admission/failure ledger
Dispatch true / commit unknown
Budget and authority gate
Client error ≠ proven rollback
Operation outcome
Not yet evaluated
Do not add retry guarantees
retryGuaranteesSuccess is false in both partial rows. Mutating retries need transaction and idempotency scope; an absent client response does not exclude duplicate effects.
Admission/failure ledger
Dispatch true / commit unknown
Budget and authority gate
Client error ≠ proven rollback
Operation outcome
Retry outcome unguaranteed / effect scope needed
Safe-error projection
Client message is The requested read is unavailable., excluding stack, secrets and internal paths. A minimal external message does not imply missing internal diagnostics.
Admission/failure ledger
Safe message / no sensitive internals
Budget and authority gate
Client error ≠ proven rollback
Operation outcome
Retry outcome unguaranteed / effect scope needed
Cleanup ownership
Reserved counters are released in finally after accepted local work. Local cleanup proves neither process-crash recovery nor remote cancellation propagation.
Admission/failure ledger
Safe message / no sensitive internals
Budget and authority gate
Local cleanup / distributed lifecycle separate
Operation outcome
Retry outcome unguaranteed / effect scope needed
Retain honest outcome
Pre-dispatch no-write is known while post-dispatch write remains unknown. Safe errors or quota success counts do not close it; commit needs its own observer evidence.
Admission/failure ledger
Safe message / no sensitive internals
Budget and authority gate
Local cleanup / distributed lifecycle separate
Operation outcome
No-dispatch known / dispatched outcome unknown

ASSUMPTION · BOUNDARY · CONTROL

Assuming an error proves nothing happened

The assumption is that a caller error proves every downstream action did not happen. That conclusion requires evidence about dispatch and commit boundaries. Our full-quota and deadline branches close before dispatch, so an untouched store follows from their concrete state order. The separate general partial-failure ledger instead records “write dispatched, response lost, commit evidence unknown” and leaves the write outcome null. This is no actual write experiment or timeout reproduction. Ask where evidence was lost and which action the retry policy applies to. A client error does not also prove server rollback, cancellation reaching every worker or complete audit. Those independent claims need integration or transaction evidence; a green ordinary-read fixture cannot replace it.

Jumping from an unknown dependency to allow

The second assumption treats opening an action after an unavailable resource or permission dependency as only an availability choice. For a protected action, converting unknown into allow also changes authorization. The risk requires a fallback to deliver protected data without necessary actor/object/action evidence. The model keeps missing permission null and closes with no dispatch and no body. Known denial retains false evidence separately; matching safe outcomes do not make those evidence states identical. A full quota does not prove the actor lacks permission, only that the selected budget is exceeded. Review necessary conditions without merging these reasons. This example performs no stress traffic, allocation bomb, endpoint fault injection or fail-open bypass.

Read every scenario without motion

Admission controls

Independent gates
Size, permission, concurrency and deadline are evaluated separately. Normal title is Tea & Bread with no write; protected fallback would require another operation/policy.
Admission records
Size/permission/concurrency/deadline distinct
Gate/counter review
Not yet evaluated
Evidence outcome
Not yet evaluated
Three negative outcomes
Quota-full, missing permission and deadline all retain no dispatch/delivery and null body. Gate reasons distinguish the same withheld result through correlation.
Admission records
Size/permission/concurrency/deadline distinct
Gate/counter review
Three reasons / no dispatch or body
Evidence outcome
Not yet evaluated
Counter-release control
Both local success and a fixed benign exception require finally counter release. This is finite reservation evidence, not actual concurrency or stress-scheduler proof.
Admission records
Size/permission/concurrency/deadline distinct
Gate/counter review
Three reasons / no dispatch or body
Evidence outcome
Success/exception cleanup / finite scope
Error-disclosure control
The client-safe message carries no stack/secret/path. Internal reason, user response and store outcome are separate projections; an empty field does not prove another success.
Admission records
Safe client projection / internal reason separate
Gate/counter review
Three reasons / no dispatch or body
Evidence outcome
Success/exception cleanup / finite scope
Commit-evidence comparison
Pre-dispatch denial has commit false; post-dispatch lost response has commit null. Keeping unknown distinct from false scopes mutating-retry decisions correctly.
Admission records
Safe client projection / internal reason separate
Gate/counter review
False commit ≠ unknown commit
Evidence outcome
Success/exception cleanup / finite scope
Bounded resource evidence
Native integer predicates and cleanup prove neither capacity, circuit breakers, cancellation nor transactions. New requirements need separate observer conditions.
Admission records
Safe client projection / internal reason separate
Gate/counter review
False commit ≠ unknown commit
Evidence outcome
Finite admission known / wider runtime unmeasured

Dispatch gap

One client error
The review sees only an unavailable client message, without dispatch or commit records. The same appearance can mean pre-dispatch denial or post-dispatch unknown outcome.
Admission records
Client error known / dispatch evidence missing
Gate/counter review
Not yet evaluated
Evidence outcome
Not yet evaluated
Do not copy expected gates
dispatch false in quota-full is not an execution record for this incomplete event. Deriving no-write from a failure label hides missing correlation and receipt.
Admission records
Client error known / dispatch evidence missing
Gate/counter review
Expected no-dispatch ≠ event evidence
Evidence outcome
Not yet evaluated
Write outcome remains open
The review retains UNKNOWN dispatch/commit/write. Retry or rollback does not guarantee the outcome; the idempotency/transaction owner needs separate context.
Admission records
Client error known / dispatch evidence missing
Gate/counter review
Expected no-dispatch ≠ event evidence
Evidence outcome
Dispatch/commit/write UNKNOWN
Required boundaries
Admission reason, dispatch receipt, operation identity and transaction outcome are needed. These comparison fields can be retained without sensitive stacks or private bodies.
Admission records
Needed: reason/dispatch/operation/commit
Gate/counter review
Expected no-dispatch ≠ event evidence
Evidence outcome
Dispatch/commit/write UNKNOWN
Cleanup gap is separate
Even counter-release evidence proves neither cancellation nor rollback. Resource budgets and persistence effects have different owners and cannot fill each other gaps.
Admission records
Needed: reason/dispatch/operation/commit
Gate/counter review
Budget release ≠ rollback or cancellation
Evidence outcome
Dispatch/commit/write UNKNOWN
Bounded review result
New evidence must show whether loss occurred before or after dispatch. This event retains client error without adding no-write, retry success or overload-control health.
Admission records
Needed: reason/dispatch/operation/commit
Gate/counter review
Budget release ≠ rollback or cancellation
Evidence outcome
Retain error / collect scoped boundary evidence

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Ownership of admission and cleanup

The defensive profile applies request-size, permission-evidence, concurrency and deadline gates before an expensive resource action. It reserves a counter only for accepted work and releases it in finally after the selected local operation. In a distributed system the counter’s node/tenant scope, atomicity and crash recovery are separate design questions; comparing two integers does not solve them. A failed permission dependency leaves the protected title withheld. Any limited public fallback is explicit under a different operation ID and policy. Prepare server diagnostic reasons and safe client messages as separate projections; expose no plaintext secret, stack or internal filesystem path. An HTTP adapter chooses statuses appropriate to its profile. The lesson’s typed code is not a universal Event ID or HTTP code for every platform.

Preserve no-dispatch and unknown-commit evidence

The independent fixture checks a successful title read and requires dispatch=0, delivery=0, write=false and body=null for full quota, missing permission and deadline expiry. A native counter test observes finally cleanup for one success and one fixed benign exception; it performs no allocation flood or real scheduler test. Unchanged data copies and request context are separate assertions. The partial-failure table never turns unknown commit into known false, particularly where retrying a mutation needs idempotency and transaction evidence. Safe error formatting limits client detail while retaining the internal reason. This scoped evidence makes the resource-protection design readable without claiming to verify real concurrency, cancellation, circuit breakers or overload capacity. Those belong to separate bounded integration tests.

NOW APPLY IT TO THE CASE

Does every client error mean no write?

The normal public read admits a 19-byte request with active1+requested1 within maxConcurrent2 and now2 below deadline10. Quota, missing permission and deadline stop before dispatch. A separate post-dispatch lost-response example has null commit evidence; it must not be equated with no dispatch.

Separate decisions for verified actor, tenant relation and requested action in the case. Do not substitute authentication or proof success for object permission.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Atlas Notes — boundary ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "profile": {
    "title": "Tea & Bread",
    "requestText": "{\"noteId\":\"note-A\"}",
    "maxBytes": 64,
    "maxConcurrent": 2,
    "deadlineTick": 10,
    "actualResourceIsolation": false,
    "actualHTTP": false,
    "actualPersistence": false
  },
  "rows": [
    {
      "case": "normal",
      "bytes": 19,
      "active": 1,
      "requested": 1,
      "permissionEvidence": true,
      "now": 2,
      "expectedDispatch": true,
      "expectedDelivery": true,
      "expectedBody": {
        "title": "Tea & Bread"
      },
      "expectedWrite": false,
      "expectedDecision": "allowed"
    },
    {
      "case": "quota-full",
      "bytes": 19,
      "active": 2,
      "requested": 1,
      "permissionEvidence": true,
      "now": 2,
      "expectedDispatch": false,
      "expectedDelivery": false,
      "expectedBody": null,
      "expectedWrite": false,
      "expectedDecision": "quota-full"
    },
    {
      "case": "permission-missing",
      "bytes": 19,
      "active": 1,
      "requested": 1,
      "permissionEvidence": null,
      "now": 2,
      "expectedDispatch": false,
      "expectedDelivery": false,
      "expectedBody": null,
      "expectedWrite": false,
      "expectedDecision": "permission-missing"
    },
    {
      "case": "deadline",
      "bytes": 19,
      "active": 1,
      "requested": 1,
      "permissionEvidence": true,
      "now": 10,
      "expectedDispatch": false,
      "expectedDelivery": false,
      "expectedBody": null,
      "expectedWrite": false,
      "expectedDecision": "deadline"
    }
  ],
  "partialFailureLedger": [
    {
      "case": "before-dispatch-denial",
      "dispatch": false,
      "commitEvidence": false,
      "writeOutcome": false,
      "retryGuaranteesSuccess": false
    },
    {
      "case": "after-write-response-lost",
      "dispatch": true,
      "commitEvidence": null,
      "writeOutcome": null,
      "retryGuaranteesSuccess": false,
      "actualWritePerformed": false
    }
  ],
  "errorProfile": {
    "clientMessage": "The requested read is unavailable.",
    "stackIncluded": false,
    "secretIncluded": false,
    "internalPathIncluded": false,
    "actualHTTPResponse": false
  },
  "rateVsConcurrency": {
    "rateLimitWindowDefined": false,
    "concurrencyProfileDefined": true,
    "universal429ForConcurrency": false,
    "retryAfterMandatory": false
  },
  "unknownEvidence": {
    "permission": null,
    "expectedDispatch": false,
    "expectedDelivery": false,
    "expectedBody": null,
    "expectedWrite": false
  },
  "boundaries": {
    "actualStress": false,
    "actualCancellation": false,
    "actualDistributedCounter": false,
    "actualCircuitBreaker": false,
    "actualTransaction": false
  },
  "knownDeniedEvidence": {
    "permission": false,
    "expectedDispatch": false,
    "expectedDelivery": false,
    "expectedBody": null,
    "expectedWrite": false
  }
}

rows: Finite admission predicate; negatives have no dispatch/delivery/write.
partialFailureLedger: After dispatch, commit can be unknown; no actual write is performed.
errorProfile: Safe client projection; includes no sensitive internal details.
unknownEvidence: Missing permission evidence differs from known denial.

Finite integers and a safe fixed local exception; not resource isolation, stress, network timeout, transaction or HTTP-response testing.

Two reality checks

An error proves the operation never happened.

Pre-dispatch evidence may establish that; lost responses can leave commit unknown.

Allow is safe when a permission service is unavailable.

Unknown evidence is not permission for a protected action; an explicit separate fallback is needed.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

maxConcurrent=2, active=2 and requested=1. Permission and byte budget pass. Is the new request dispatched?

No. quota-full with no body or dispatch.
Yes. Permission true removes every resource limit.

Read the explained answer

No. quota-full with no body or dispatch. — The total 2+1 exceeds the limit of 2. Permission success does not override resource quota.

Permission null and false both stop dispatch. Do they mean the same evidence?

Selected lesson artifact fields; teaching example

unknownEvidence: {"permission":null,"expectedDispatch":false,"expectedDelivery":false,"expectedBody":null,"expectedWrite":false}
knownDeniedEvidence: {"permission":false,"expectedDispatch":false,"expectedDelivery":false,"expectedBody":null,"expectedWrite":false}

Yes. Null always means explicit policy denial or proven attack.
No. Null is unknown; false is a known denial.

Read the explained answer

No. Null is unknown; false is a known denial. — Both withhold a body, but for different reasons. Missing evidence is neither automatic allow nor proven hostile behavior.

Why do deadline and concurrency rejections not universally imply HTTP 429? Does an absent response prove an earlier write was undone?

Read the explained answer

This finite profile defines concurrency admission, not a rate-limit window. HTTP status and Retry-After policy are separate; universal429ForConcurrency=false. An absent response alone does not establish commit or write outcome, so the conceptual after-write-response-lost case remains unknown. That branch is not a real write or cancellation test. The client error message must not disclose internal paths, stacks or secrets.

□ I did not treat concurrency quota as a rate window or universal status.

□ I did not treat an absent response as guaranteed business rollback.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

OWASP Denial of Service Cheat SheetSoftware Design Concepts: cheap validation, graceful degradation/bulkheads · Input validation: total request size and bounded resource allocation
OWASP Authorization Cheat SheetDeny by Default · Validate the Permissions on Every Request
OWASP Error Handling Cheat SheetObjective: generic client response with server-side diagnostics
RFC9457 Problem Details for HTTP APIs§5 Security Considerations: limit sensitive implementation detail exposure
RFC6585 Additional HTTP Status Codes§4 429 Too Many Requests / optional Retry-After / unspecified counting scope
RFC9110 HTTP Semantics§9.2.2 Idempotent Methods: response loss, intended effect and non-idempotent automatic retry conditions

YOUR NOTES / THIS BROWSER

Resource limits, errors and fail-open boundaries

1. Core · Mechanism

Read allowed

Quota full

Permission absent

Deadline reached

Quotas and permission do not substitute for each other

Deadlines, cancellation and partial failure

Error format and the scope of evidence

The permission boundary of graceful degradation

2. Red · Trust & Impact

Quota/permission

Partial outcome

Assuming an error proves nothing happened

Jumping from an unknown dependency to allow

3. Blue · Secure development & defense

Admission controls

Dispatch gap

Ownership of admission and cleanup

Preserve no-dispatch and unknown-commit evidence

Does every client error mean no write?

Two reality checks

maxConcurrent=2, active=2 and requested=1. Permission and byte budget pass. Is the new request dispatched?

Permission null and false both stop dispatch. Do they mean the same evidence?

Why do deadline and concurrency rejections not universally imply HTTP 429? Does an absent response prove an earlier write was undone?

Sources and scope