Back to Signal Feed
CodeTracked since May 19, 2026

Write-endpoint limiter now returns clear 429 feedback and supports live S3 limit config

InsForge updated write-endpoint rate limiting so exhausted retry cases now return explicit rate-limit errors instead of being repackaged as generic 500s, and moved per-category write quotas (functions, deployments, compute) to a live S3 JSON config refreshed on a schedule.

write-endpoint rate limitingAppError(429)RATE_LIMITEDS3 config

What Happened

  • InsForge updated write-endpoint rate limiting so exhausted retry cases now return explicit rate-limit errors instead of being repackaged as generic 500s, and moved per-category write quotas (functions, deployments, compute) to a live S3 JSON config refreshed on a schedule.
  • InsForge updated write-endpoint rate limiting so exhausted retry cases now return explicit rate-limit errors instead of being repackaged as generic 500s, and moved per-category write quotas (functions, deployments, compute) to a live S3 JSON config refreshed on a schedule.
  • 1 evidence item attached for review.

What is Different

Before

Scattered source updates, isolated context, and manual follow-up across multiple feeds.

Now

Implemented a rate-limit behavior fix and configuration path: retry-exhausted write calls now propagate AppError(429, RATE_LIMITED) to callers, and write quotas are now externally configurable per category from S3 so updates can take effect via refresh without rebuilding middleware.

Why Track This

Why It Matters

API clients and platform operators using write APIs will now get a visible 429 rate-limit signal instead of a hidden 500, so client backoff logic can work correctly during throttling and operators can tune limits without code changes. This closes a silent-failure loop that could mask throttling as server errors. The practical next watch point is whether downstream callers consistently honor RATE_LIMITED responses, because ignoring them can still cause retry storms despite the clearer signal.

Impact

API clients and platform operators using write APIs will now get a visible 429 rate-limit signal instead of a hidden 500, so client backoff logic can work correctly during throttling and operators can tune limits without code changes. This closes a silent-failure loop that could mask throttling as server errors. The practical next watch point is whether downstream callers consistently honor RATE_LIMITED responses, because ignoring them can still cause retry storms despite the clearer signal.

What To Watch Next

  • Watch whether write-endpoint rate limiting becomes a repeated pattern.
  • Track follow-up changes around AI Governance and Compliance.
  • Compare future signals against this evidence trail.
  • Re-check risk flags: s3_rate_limit_config_fetch_failure, stale_limits_between_refreshes.
Open Topic TimelineOpen Technical EventOpen Original Sources3_rate_limit_config_fetch_failure / stale_limits_between_refreshes / partial_or_invalid_json_config / clients_not_honoring_429 / default_fallback_hiding_bad_config

Supporting Evidence

GITHUB COMMIT BURSTHigh Trust

InsForge/InsForge commit burst: 8 commits in 7 days

Rate-limit retry exhaustion now throws AppError(429, RATE_LIMITED), and write-endpoint caps are loaded from AWS_CONFIG_BUCKET/write-endpoint-rate-limits.json with hourly refresh.