actors info --input/--readme should follow the Actor's default build, not the latest tag #1454

apify actors info <actor> --input and --readme resolve the build through taggedBuilds.latest. That tag is a convention — a per-version default that an Actor author can rename or drop. What the platform actually runs is a configuration: the Actor's defaultRunOptions.build. When the two disagree, the CLI reports on a build that nobody runs, or reports nothing at all.

Version 1.10.0, both installs (npm/node and the bundled build).

Problem 1 — an Actor without a latest tag looks like it has no schema

$ apify actors info apify/cheerio-scraper --input
Error: No input schema found for this Actor.
$ echo $?
0

Same for --readme. But the schema is there — apify/cheerio-scraper tags its builds beta, development, version-1, version-2, version-3, and its default build (version-3) is 3.0.22, with a 30-field input schema and a 32,059-character README:

$ curl -s https://api.apify.com/v2/acts/apify~cheerio-scraper/builds/default \
    | jq '.data.actorDefinition.input.properties | length'
30

Two things make this awkward to notice: the message goes to stdout, and the exit code is 0 — so a pipeline can't tell it from a successful run.

Problem 2 — when both exist but differ, the output is silently wrong

apify/rag-web-browser has latest → 0.0.32 while its default build is version-1 → 1.0.28. Both schemas have 15 properties, so nothing looks off, but six of them differ:

data_xplorer/google-news-scraper-fast is worse: latest → 0.0.29 exposes 5 properties and calls the search field keyword, while the default build stable → 2.8.12 exposes 10 and calls it keywords. An input built from actors info --input fails against the Actor that actually runs.

This is the case that motivated the report — Problem 1 is at least loud.

Where it comes from

src/commands/actors/info.ts#L124 (v1.10.0):

const latest = actorInfo.taggedBuilds?.latest;

--readme and --input both bail out on !latest. The hydration loop just above (L108–117) already fetches every tagged build, and actorInfo.defaultRunOptions.build is part of the same response — so picking the right one needs no extra request:

const defaultTag = actorInfo.defaultRunOptions?.build ?? 'latest';
const target = actorInfo.taggedBuilds?.[defaultTag] ?? actorInfo.taggedBuilds?.latest;

Definitions I worked from

• buildTag is a property of an Actor version — "Tag that is automatically set to the latest successful build of the current version", default latest (POST /v2/acts/{actorId}/builds, POST /v2/acts/{actorId}/versions). Nothing requires an Actor to have a version tagged latest.
• defaultRunOptions.build is a field on the Actor, editable via PUT /v2/acts/{actorId}. This is what a run without an explicit build uses.
• GET /v2/acts/{actorId}/builds/default resolves it server-side, and needs no token for a public Actor.

What I checked

20 Actors — 9 first-party apify/*, 11 community — each compared three ways: actors info --input, actors info --input --json + jq, and builds/default.

• 5 have no latest tag and fail Problem 1, all of them first-party crawlers: cheerio-scraper, web-scraper, playwright-scraper, puppeteer-scraper, website-content-crawler. The other 4 first-party Actors sampled do have latest, as did all 11 community ones — so this isn't a first-party/community split, it's a house style among the crawlers.
• 2 of the remaining 15 hit Problem 2 (the two above).
• builds/default matched taggedBuilds[defaultRunOptions.build] in 20/20 — which is why the suggested fix uses the data already in the response rather than a new endpoint.

Workaround in the meantime is builds/default over plain HTTP, which is a shame for a CLI that otherwise covers this.

Is following defaultRunOptions.build (with latest as fallback) the behaviour you'd want here, or is the latest coupling deliberate? Happy to open a PR either way.

_{Found while validating Actor-tooling docs in apify/awesome-skills — several skills tell agents to fetch input schemas with apify actors info --input.}