Farther ShoreDocs
Go to Farther Shore
Understand gateway behavior
Consuming the API
Monetary admission
Usage limits
Gate API routes by plan
Diagnose a denied request
OutcomePrerequisitesCapture evidenceWalk the boundaries in orderVerifyRecoveryAgent prompt
Response & deny codes
gateway HTTP contracts
Status
Docs/Cookbook/Diagnose a denied request

Diagnose a denied request

Use the recorded request id and accepted environment contract to find the first failing authorization or limit boundary.

Outcome

The exact enforcement boundary and owning state are known before retrying or changing a plan, permission, limit, or backend.

Prerequisites

  • The denied response's request id and environment.
  • The original method, path, caller, and timestamp.
  • Read access to denial, contract, route, analytics, and backend state.

Capture evidence

Keep the response status, code, limitCode, _fs, X-FS-Decision-Id, request id, method, path, caller, and environment. Do not retry yet.

bash
farthershore denial show acme <requestId> --format json
farthershore analytics log acme --range 1h --domain denials --limit 100 --format json
farthershore business status acme --format json
farthershore business routes acme --env production --format json
farthershore business contract acme --env production --format json

Walk the boundaries in order

  1. Confirm the credential belongs to this business and environment.
  2. Confirm method and path matched the expected compiled route.
  3. Confirm the active plan grants that route.
  4. For a member request, confirm the effective Managed-RBAC permission.
  5. Read _fs.limitClass for quota, rate, concurrency, capacity, spend, or provider throttling.
  6. Only after gateway admission passed, inspect backend health and application logs.
bash
farthershore backend list acme --format json

Reproduce at most once with the same customer and environment. A hard quota, capacity, entitlement, or permission denial will not improve through rapid retry. A rate or concurrency denial should follow _fs.reaction and Retry-After.

Fix repository-owned causes in the Business program and test them in preview. Fix customer state through the narrow consumer operation. Do not broaden a plan or role merely to make one test pass.

See Diagnose limits and denials.

Verify

After correcting the owning fact, reproduce once with the same customer, environment, method, and path. Require either the intended success or the same documented expected denial.

Recovery

Fix repository-owned policy in business/ and push it through preview. Fix customer state with the narrow customer operation. Follow Retry-After only for a retryable rate/concurrency decision; do not retry hard denials rapidly.

Agent prompt

Diagnose this one denied request by preserving its ids, reading denial details,
and walking credential, route, plan, role, and limit boundaries in order.
Report the first failing boundary before making any change.
PreviousGate API routes by planNextResponse & deny codes

On this page

OutcomePrerequisitesCapture evidenceWalk the boundaries in orderVerifyRecoveryAgent prompt