blobhub blob limits

blob limits shows the limits in force for a blob — quotas like revisions_per_blob, and the workflow_component_code_imports allowlist that decides which third-party modules a revision’s code may import. It is the one command in this group a read- or write-scoped key cannot run at all, and that single fact explains behaviour across several other commands. This page is where it is stated.

Synopsis

blobhub blob limits <org>/<blob> [--refresh]

Argument	Default	Description
`blob`	required	Blob as `<org>/<name>`, or a bare name with `--org`.

Flag	Default	Description
`--refresh`	off	Also refresh the compiler’s local allowlist cache.

What it does

One call, to the blob’s limits route. Unlike its two siblings it never fetches the blob record first — the limits route is the only request it makes.

Limits for acme/dragon-ops
  revisions_per_blob                       actual=12, maximum=50
  workflow_component_code_imports          value=['numpy', 'pandas']
  workflow_definitions_per_revision        actual=4, maximum=100

Entries print one per line, sorted by name, with each entry’s own fields sorted and rendered as key=value. Numeric limits carry a maximum, plus an actual where the platform tracks usage; metadata limits such as the import allowlist carry a value instead. What you get back is the merged hierarchy, not just the limits set on the blob: the platform walks from the blob up through its ancestors and merges them, with the nearest target winning per field. So the set you see is neither fixed nor exhaustive — it is whatever has been configured for this blob and everything above it. Under --json the payload carries blob, limits, refreshed, and cache_path (null without --refresh).

Reading limits requires an `admin` key

The limits routes check for the admin role. The read and write keys the platform itself recommends for automation get a 403. This was confirmed against the deployed API with a real write key, not inferred from the handler. That one fact is the reason for behaviour on several other commands, all of which have to work under exactly the keys that cannot read limits:

Where	What the missing `admin` key causes
`workflow build`, `diff`, `deploy`	The live allowlist read `403`s, so the compiler falls back to its local cache. An import it still cannot resolve degrades from the hard failure `IMPORT_UNAVAILABLE` to the `IMPORT_UNVERIFIED` advisory — the build proceeds and tells you it could not verify. `--strict-imports` restores the hard failure on `build` and `deploy`; `diff` has no such flag, since it writes nothing to fail late.
`blobhub blob revisions`	The truncation check compares the returned count against `revisions_per_blob`. Unreadable, so the check never runs and `REVISION_LIST_TRUNCATED` cannot fire.
`workflow ls`	The same, against `workflow_definitions_per_revision`, for `DEFINITION_LIST_TRUNCATED`.
`scheduler deploy`	Validating a schedule’s `target.workflow` alias means confirming the definition listing was complete, which needs the same limit. Without it the check still refuses an alias it cannot find, but says so in a message that names its own uncertainty rather than claiming the definition does not exist.

This command does not degrade. A 403 is a hard LIMITS_NOT_ACCESSIBLE, deliberately unlike the compiler’s allowlist read that swallows the same 403 and falls back to cache. The difference is what the caller asked for: a build wants imports checked, and a cached answer serves that; this command was asked for the limits, and a partial answer quietly sourced from a week-old file is worse than a clear refusal. And it will not name a cause it cannot know. The same handler answers 403 for a blob it cannot find, so the message names both possibilities — not an admin key, or no such blob — and asserts neither. Sending someone off to mint an admin key over a typo’d blob name is a worse failure than saying plainly that the platform conflates the two.

`--refresh` and the compiler’s allowlist cache

--refresh writes the module list from workflow_component_code_imports into the cache that build, diff and deploy fall back on, under ~/.blobhub/cache/allowlist/, at mode 0600, alongside the fetch timestamp and the org and blob it came from. One more line follows the limits, naming the file it wrote:

Allowlist cache written to /Users/you/.blobhub/cache/allowlist/acme/dragon-ops.yaml

That same path is the --json payload’s cache_path. A live allowlist read already writes that cache, so a build under an admin key refreshes it on its own. The flag is for when the key that can read limits is not the key that runs the build: an operator with an admin key seeds the cache, and later builds under a write key read it. The cache is per-machine, so this helps where the seeding and the building happen on the same machine or in the same image. Before relying on it, know how the cache is keyed and when it goes stale. The cache key is your reference as you typed it, lower-cased — org-qualified exactly when your reference is. build keys on the manifest’s blob: field the same way, as written. So a manifest saying blob: dragon-ops reads a different cache entry from the one blobhub blob limits acme/dragon-ops --refresh writes, and the refresh you just ran would change nothing:

# for a manifest whose blob: field is 'dragon-ops', refresh the bare name
blobhub --org acme blob limits dragon-ops --refresh

A cache entry goes stale after seven days. Past that, a build reading it raises ALLOWLIST_STALE and blobhub doctor’s allowlist row warns, naming the entry and its age. This command is how you clear that.

Errors

Code	When
`LIMITS_NOT_ACCESSIBLE`	The limits read returned `403`: this key is not `admin`-scoped, or the blob is absent. The platform returns the same `403` for both.
`BLOB_REFERENCE_INVALID`	The reference is empty, carries more than one `/`, has an empty org before the `/`, has no blob name, or is a bare name with no `--org` and no `BLOBHUB_ORG`.
`MANIFEST_INVALID`	`--refresh` only, and despite the name: the reference cannot be turned into a cache-file path. No empty, `.`, `..`, absolute, or backslash-bearing segments. The code is shared with the manifest loader, which is the other caller of the same normalizer.
`CREDENTIALS_NOT_FOUND`	No API key from flags, environment, or credentials file.
`PROFILE_NOT_FOUND`	`BLOBHUB_PROFILE` names a profile that is not stored.
`INSECURE_CREDENTIALS_PERMISSIONS`	`credentials.yaml` is readable by group or other.
`API_RATE_LIMITED`, `API_TRANSIENT_ERROR`, `API_NETWORK_ERROR`	The limits call failed after its retries.

BLOB_NOT_ACCESSIBLE never appears here. This command never fetches the blob record, so an absent blob reaches you as LIMITS_NOT_ACCESSIBLE instead — which is also all the platform said.

Overview

Workflow

Scheduler

blobhub blob limits

Synopsis

What it does

Reading limits requires an `admin` key

`--refresh` and the compiler’s allowlist cache

Errors

See also

​Synopsis

​What it does

​Reading limits requires an admin key

​--refresh and the compiler’s allowlist cache

​Errors

​See also

Synopsis

What it does

Reading limits requires an `admin` key

`--refresh` and the compiler’s allowlist cache

Errors

See also