Problem
The published actor schema at packages/json_schemas/schemas/actor.schema.json:25 defines the .version pattern as:
"pattern": "^([0-9]+)\\.([0-9]+)(\\.[0-9]+){0,1}$"
This regex accepts BOTH 2-part MAJOR.MINOR and 3-part MAJOR.MINOR.PATCH version strings.
However, the actual platform admission gate in apify-core (src/packages/simple-schema/src/regexs.ts:2) enforces a stricter regex:
^([0-9]|[1-9][0-9])\.([0-9]|[1-9][0-9])$
This is MAJOR.MINOR only, each segment 0-99. Empirically verified 2026-06-17 on test Actor pYSXdpQa55nSb6SID: "version": "1.0.0" is rejected at POST /v2/acts/{id}/versions.
Consequence: every third-party linter, IDE integration, or SDK that validates against the published @apify/json_schemas reports 3-part SemVer as valid — but the platform rejects it on push. Users (and agents that consume the schema) get contradictory signals from the two sources of truth.
Proposal
Two coordinated changes:
-
Tighten the published regex in packages/json_schemas/schemas/actor.schema.json:25 to match the platform:
"pattern": "^([0-9]|[1-9][0-9])\\.([0-9]|[1-9][0-9])$"
-
Export the regex as a shared constant so apify-core can consume a single source of truth (currently defined in two places that could drift again). Options:
- Export from
@apify/consts as MAJOR_MINOR_VERSION_REGEX.
- Or add a
packages/utilities helper assertValidActorJsonVersion(v: string).
Then update apify-core src/packages/simple-schema/src/regexs.ts:2 to import the shared constant.
Impact
Medium. Every external tool that validates against the published schema (Renovate/Dependabot custom manifests, IDE JSON validators, third-party SDKs) reports false-positive "valid" for 3-part SemVer. Combined with apify-docs's three "1.0.0" examples (separate issue against apify-docs) and the CLI's lack of client-side validation before upload, the whole MAJOR.MINOR invariant is under-defended.
Related
- Cross-refs:
apify-docs fix for three "1.0.0" docs examples; apify-cli client-side validation before upload; apify-core regex constant unification.
Surfaced during an evaluation of Apify surfaces for agent-driven Actor development.
Problem
The published actor schema at
packages/json_schemas/schemas/actor.schema.json:25defines the.versionpattern as:This regex accepts BOTH 2-part
MAJOR.MINORand 3-partMAJOR.MINOR.PATCHversion strings.However, the actual platform admission gate in apify-core (
src/packages/simple-schema/src/regexs.ts:2) enforces a stricter regex:This is
MAJOR.MINORonly, each segment0-99. Empirically verified 2026-06-17 on test ActorpYSXdpQa55nSb6SID:"version": "1.0.0"is rejected atPOST /v2/acts/{id}/versions.Consequence: every third-party linter, IDE integration, or SDK that validates against the published
@apify/json_schemasreports 3-part SemVer as valid — but the platform rejects it on push. Users (and agents that consume the schema) get contradictory signals from the two sources of truth.Proposal
Two coordinated changes:
Tighten the published regex in
packages/json_schemas/schemas/actor.schema.json:25to match the platform:Export the regex as a shared constant so apify-core can consume a single source of truth (currently defined in two places that could drift again). Options:
@apify/constsasMAJOR_MINOR_VERSION_REGEX.packages/utilitieshelperassertValidActorJsonVersion(v: string).Then update apify-core
src/packages/simple-schema/src/regexs.ts:2to import the shared constant.Impact
Medium. Every external tool that validates against the published schema (Renovate/Dependabot custom manifests, IDE JSON validators, third-party SDKs) reports false-positive "valid" for 3-part SemVer. Combined with
apify-docs's three"1.0.0"examples (separate issue against apify-docs) and the CLI's lack of client-side validation before upload, the wholeMAJOR.MINORinvariant is under-defended.Related
apify-docsfix for three"1.0.0"docs examples;apify-cliclient-side validation before upload;apify-coreregex constant unification.Surfaced during an evaluation of Apify surfaces for agent-driven Actor development.