fix(space): public board create() methods raise HTTP 500 on invalid anchor (DeployBoard.DoesNotExist unhandled)

[eltypical]

Summary

create() (and partial_update(), destroy()) methods in the public board ViewSets call DeployBoard.objects.get(anchor=anchor, ...) without try/except. An invalid or expired anchor value raises an unhandled DoesNotExist → HTTP 500. Correct behavior is HTTP 404.

Inconsistency

get_queryset() in all ViewSets already handles this correctly:

def get_queryset(self):
    try:
        project_deploy_board = DeployBoard.objects.get(...)
    except DeployBoard.DoesNotExist:
        return IssueComment.objects.none()  # safe fallback

create() methods do not:

def create(self, request, anchor, issue_id):
    project_deploy_board = DeployBoard.objects.get(anchor=anchor, entity_name="project")
    # ← raises DoesNotExist → HTTP 500 if anchor is invalid/expired

Impact

• Availability: Invalid anchor → server error in logs + 500 to client.
• Security: Minor — error signal distinguishable from 404. No data leaked.

Recommended Fix

def create(self, request, anchor, issue_id):
    try:
        project_deploy_board = DeployBoard.objects.get(anchor=anchor, entity_name="project")
    except DeployBoard.DoesNotExist:
        return Response({"error": "Project board not found."}, status=status.HTTP_404_NOT_FOUND)

Apply to all create(), partial_update(), and destroy() methods in:

• IssueCommentPublicViewSet
• IssueVotePublicViewSet
• IssueReactionPublicViewSet
• CommentReactionPublicViewSet

Affected File

apps/api/plane/space/views/issue.py

Related

Identified during security audit of PR #9498. Pre-existing issue, not introduced by that PR.

[lurui1997]

I tried to reproduce this before writing a fix, and the 500 does not occur — every route listed here already returns 404.

DeployBoard.DoesNotExist subclasses django.core.exceptions.ObjectDoesNotExist, and both shared base views in plane/space/views/base.py map that to a 404:

if isinstance(e, ObjectDoesNotExist):
    return Response(
        {"error": "The required object does not exist."},
        status=status.HTTP_404_NOT_FOUND,
    )

BaseAPIView.dispatch / BaseViewSet.dispatch both funnel handler exceptions into that method, so the unguarded DeployBoard.objects.get(anchor=...) calls in create() / partial_update() / destroy() never reach the client as a 500. Note also that this branch returns before log_exception(e), so the "server error in logs" impact does not happen either.

Measured

Django + DRF against Postgres, DJANGO_SETTINGS_MODULE=plane.settings.test, using an anchor with no DeployBoard row. Run under both DEBUG=True and DEBUG=False, since DRF's raise_uncaught_exception branches on settings.DEBUG:

Route	Method	Status
/api/public/anchor/{a}/issues/{id}/	GET	404
/api/public/anchor/{a}/issues/{id}/comments/	POST	404
/api/public/anchor/{a}/issues/{id}/comments/{pk}/	PATCH	404
/api/public/anchor/{a}/issues/{id}/comments/{pk}/	DELETE	404
/api/public/anchor/{a}/issues/{id}/reactions/	POST	404
/api/public/anchor/{a}/issues/{id}/reactions/{code}/	DELETE	404
/api/public/anchor/{a}/comments/{id}/reactions/	POST	404
/api/public/anchor/{a}/comments/{id}/reactions/{code}/	DELETE	404
/api/public/anchor/{a}/issues/{id}/votes/	POST	404
/api/public/anchor/{a}/issues/{id}/votes/	DELETE	404

Every response body was {"error": "The required object does not exist."}, which confirms the 404 comes from the base-class handler rather than from URL resolution (that would render HTML). caplog captured 0 ERROR-level records across all ten.

On the proposed patch

I'd suggest not applying it as written. It would not change any status code, and replacing the body with {"error": "Project board not found."} alters a response that is already shipped, so clients matching on that string would break. #9498 is also open against these same methods, so the edits would conflict.

What does seem worth having

The correct status code currently rests on a base class several layers removed from the views that depend on it, and no test pins that. A refactor of handle_exception() could turn all ten routes into 500s without any test failing — which is probably the version of this concern that has real teeth.

I've opened #9510 with regression coverage for all ten routes. It adds only test files, touches no line of plane/space/views/issue.py, and therefore doesn't conflict with #9498 (I checked that the new tests still pass against that PR's guards, since its _issue_belongs_to_board checks run after the board lookup).

Happy to close this as not reproducible if you agree with the reading above.