Summary
Point the SDK's arcpy/toolbox translator at the server-side validation endpoint so translation reports become server-attested rather than SDK-local assertions.
honua-server adds POST /api/v{version}/admin/import/toolbox/translation/validate (honua-io/honua-server#3040, issue honua-io/honua-server#2145). It validates a translated toolbox mapping against the canonical GP process catalog and returns a per-tool classification (translated / partially-translated / unsupported) with the specific reasons a tool cannot be fully translated.
Today honua-migrate produces that verdict locally from the SDK's own view of the catalog. That means a report can disagree with the server that would actually run the job — the SDK can call a tool translated when the server's submit validator would reject it, or flag it unsupported when the server would accept it. Migration reports are used to decide whether a migration is viable, so a locally-derived verdict that drifts from the server is worse than no verdict.
Why this matters now
This is the last remaining tail of honua-io/honua-server#2145, which is the last open child of the GP porting epic honua-io/honua-server#1259. Everything else in that epic has landed. Once this ships, #2145 and #1259 can both close.
Explicitly NOT in scope — proprietary binary formats
This issue does not ask for binary .tbx parsing, and that must not be added. The current handling is correct and deliberate, and should stay:
.pyt (plain-text Python toolbox) → parse_pyt_file ✅ supported
.atbx (open ModelBuilder toolbox) → modelbuilder.parse_atbx_toolbox ✅ supported
- binary
.tbx → UnsupportedToolboxError, with guidance to export to .atbx or .pyt
migration/modelbuilder.py states the standing position directly: "we never parse the proprietary binary .tbx". Honua's migration path for proprietary Esri containers is export-to-open-format, never reverse-engineering the container — the same rule that governs Esri locator files (.loc/.lox). UnsupportedToolboxError is a policy decision, not an unimplemented stub, and it should not be "fixed".
If anything, the actionable improvement here is making that refusal more helpful — see the optional item below.
Acceptance criteria
Dependencies
Cross-links
Summary
Point the SDK's arcpy/toolbox translator at the server-side validation endpoint so translation reports become server-attested rather than SDK-local assertions.
honua-serveraddsPOST /api/v{version}/admin/import/toolbox/translation/validate(honua-io/honua-server#3040, issue honua-io/honua-server#2145). It validates a translated toolbox mapping against the canonical GP process catalog and returns a per-tool classification (translated/partially-translated/unsupported) with the specific reasons a tool cannot be fully translated.Today
honua-migrateproduces that verdict locally from the SDK's own view of the catalog. That means a report can disagree with the server that would actually run the job — the SDK can call a tool translated when the server's submit validator would reject it, or flag it unsupported when the server would accept it. Migration reports are used to decide whether a migration is viable, so a locally-derived verdict that drifts from the server is worse than no verdict.Why this matters now
This is the last remaining tail of honua-io/honua-server#2145, which is the last open child of the GP porting epic honua-io/honua-server#1259. Everything else in that epic has landed. Once this ships, #2145 and #1259 can both close.
Explicitly NOT in scope — proprietary binary formats
This issue does not ask for binary
.tbxparsing, and that must not be added. The current handling is correct and deliberate, and should stay:.pyt(plain-text Python toolbox) →parse_pyt_file✅ supported.atbx(open ModelBuilder toolbox) →modelbuilder.parse_atbx_toolbox✅ supported.tbx→UnsupportedToolboxError, with guidance to export to.atbxor.pytmigration/modelbuilder.pystates the standing position directly: "we never parse the proprietary binary.tbx". Honua's migration path for proprietary Esri containers is export-to-open-format, never reverse-engineering the container — the same rule that governs Esri locator files (.loc/.lox).UnsupportedToolboxErroris a policy decision, not an unimplemented stub, and it should not be "fixed".If anything, the actionable improvement here is making that refusal more helpful — see the optional item below.
Acceptance criteria
honua-migrate translate(and the corresponding library entrypoint) can submit a translated mapping to the server validation endpoint and incorporate the server's per-tool classification into the report.UnsupportedToolboxErroris raised for a binary.tbx, include the concrete ArcGIS Pro export steps to produce a.pyt/.atbx, so the error is a migration instruction rather than a dead end.Dependencies
trunkyet). Worth confirming the merged route and response shape before implementing, rather than coding against the PR.Cross-links