Describe the bug
On a self-hosted Community edition instance, every plane-compose command that loads the remote project schema (plane pull, plane diff, and by code path plane push / plane validate) fails with:
ERROR API error 404: Page not found.
Error: Failed to load project schema: list not found. Check your network
connection and API credentials, then retry.
The cause is a mismatch between the status code the code expects and the one Community edition returns.
planecompose/backend/plane.py::_fetch_types already anticipates "this deployment doesn't have work item types" — but it only handles 402:
# Returns empty list on 402 (free tier — work item types not available).
...
except APIError as e:
if e.status_code == 402:
logger.warning(
"Work item types not available on this plan (402) — using empty types list"
)
return []
raise
Plane Cloud's free tier answers 402 Payment Required. A self-hosted Community instance never registers the route at all and answers 404, which falls through to raise and aborts the command.
Confirmed the 404 comes from Plane itself, not from a proxy or CDN:
HTTP/2 404
content-type: application/json
{"error": "Page not found."}
GET /api/v1/workspaces/{slug}/projects/{id}/work-item-types/ — the exact path built by plane-sdk (plane/api/work_item_types.py:89) — 404s for every project in the workspace, while states/, labels/ and members/ all return 200.
Note the CLI also logs Checking workspace_work_item_types feature for omf: False immediately before making the call, so the unavailability is already detected at the workspace level; the project-level fetch happens regardless.
Steps to reproduce
- Self-host Plane Community edition (v1.4.0).
plane auth login with a PAT, plane init a project, plane push the schema.
- Run
plane pull or plane diff.
Result: the command aborts with the error above. plane pull --work-only --no-properties does not avoid it. plane status works, since it doesn't touch the remote schema.
Expected behavior
Treat 404 the same as 402 — a deployment without the work item types API should degrade to an empty types list, not abort. Something like:
if e.status_code in (402, 404):
logger.warning(
f"Work item types not available on this deployment ({e.status_code}) "
"— using empty types list"
)
return []
Alternatively, honour the workspace_work_item_types: False result that is already computed and skip the fetch entirely.
Without this, plane-compose is unusable against Community self-hosts for anything beyond plane status.
Environment
- plane-compose 0.5.2, plane-sdk 0.2.21, Python 3.11, macOS
- Plane instance: v1.4.0, edition PLANE_COMMUNITY, self-hosted behind Caddy
- Project has
is_issue_type_enabled: false
Describe the bug
On a self-hosted Community edition instance, every plane-compose command that loads the remote project schema (
plane pull,plane diff, and by code pathplane push/plane validate) fails with:The cause is a mismatch between the status code the code expects and the one Community edition returns.
planecompose/backend/plane.py::_fetch_typesalready anticipates "this deployment doesn't have work item types" — but it only handles 402:Plane Cloud's free tier answers
402 Payment Required. A self-hosted Community instance never registers the route at all and answers404, which falls through toraiseand aborts the command.Confirmed the 404 comes from Plane itself, not from a proxy or CDN:
GET /api/v1/workspaces/{slug}/projects/{id}/work-item-types/— the exact path built by plane-sdk (plane/api/work_item_types.py:89) — 404s for every project in the workspace, whilestates/,labels/andmembers/all return 200.Note the CLI also logs
Checking workspace_work_item_types feature for omf: Falseimmediately before making the call, so the unavailability is already detected at the workspace level; the project-level fetch happens regardless.Steps to reproduce
plane auth loginwith a PAT,plane inita project,plane pushthe schema.plane pullorplane diff.Result: the command aborts with the error above.
plane pull --work-only --no-propertiesdoes not avoid it.plane statusworks, since it doesn't touch the remote schema.Expected behavior
Treat
404the same as402— a deployment without the work item types API should degrade to an empty types list, not abort. Something like:Alternatively, honour the
workspace_work_item_types: Falseresult that is already computed and skip the fetch entirely.Without this, plane-compose is unusable against Community self-hosts for anything beyond
plane status.Environment
is_issue_type_enabled: false