== WHY (KEEP THIS — IT'S WHY THE FORK EXISTS) ==
Vanilla Plane's upload flow uses AWS S3 PostObject (presigned POST +
multipart/form-data + signed-policy-document). Cloudflare R2 AND
Backblaze B2 — the two most common self-host S3-compatible backends —
both return HTTP 501 NotImplemented for PostObject. Empirically verified
2026-04-30 against B2 s3.us-west-004.backblazeb2.com from inside Plane's
own prod api container, replicating Plane's exact boto3 call:
PUT against B2: 200 OK
POST against B2: 501 NotImplemented "This API call is not supported."
POST against R2: 501 NotImplemented (failure that started this thread)
The error code is `NotImplemented` (not `SignatureDoesNotMatch` etc),
meaning the server rejects the verb itself — no boto3 config, addressing-
style flag, or signature variant fixes it. Tested both path-style and
virtual-hosted-style URLs against B2; both fail identically for POST.
This patch rewrites the upload flow to use presigned PUT, which is
universally supported (R2, B2, AWS S3 native, MinIO, Wasabi, etc).
== WHAT (FIVE-FILE BACKEND, FIVE-FILE FRONTEND) ==
Backend:
* apps/api/plane/settings/storage.py — S3Storage.generate_presigned_post
now mints a presigned PUT URL via generate_presigned_url(HttpMethod="PUT").
Method name kept for caller compat. Response shape:
{url, method: "PUT", fields: {Content-Type, key}}.
* apps/api/plane/utils/openapi/responses.py — example response updated.
* apps/api/plane/tests/unit/settings/test_storage.py — 2 tests updated to
assert the new boto3 call.
Frontend:
* packages/types/src/file.ts — TFileSignedURLResponse.upload_data adds
optional method?: "PUT" | "POST"; drops AWS POST-form-data fields.
* packages/services/src/file/helper.ts — generateFileUploadPayload now
returns a TFileUploadRequest descriptor (url+method+body+headers) that
dispatches on method. POST branch kept for upstream parity but the
fork backend never emits POST.
* packages/services/src/file/file-upload.service.ts +
apps/web/core/services/file-upload.service.ts — uploadFile signature
changes from (url, FormData, progress?) to (payload, progress?).
* 5 caller sites updated (apps/web/core/services/file.service.ts x3,
issue_attachment.service.ts x1, sites-file.service.ts x1).
== TRADEOFFS ACCEPTED ==
* Lost: signed `content-length-range` enforcement at the storage layer.
Server-side validation in the API view still rejects oversized requests
with 413 before minting the URL, so a determined client could only
over-upload by misreporting size, capped at the bucket's own size limit.
* Different request shape on the wire (PUT with raw binary body vs POST
with multipart form). Externally invisible to users.
== ROLLBACK ==
If this becomes a maintenance nightmare:
git revert <this-commit-sha>
# rebuild + push images, swap compose tags, redeploy
After revert, uploads will only work against backends that implement
PostObject (MinIO, AWS S3 native). R2 and B2 will return 501 again.
== FULL DECISION RECORD ==
binarybeachio repo: docs/features/storage-upload-flow.md
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| contract | ||
| smoke | ||
| unit | ||
| __init__.py | ||
| apps.py | ||
| conftest.py | ||
| conftest_external.py | ||
| factories.py | ||
| README.md | ||
| TESTING_GUIDE.md | ||
Plane Tests
This directory contains tests for the Plane application. The tests are organized using pytest.
Test Structure
Tests are organized into the following categories:
- Unit tests: Test individual functions or classes in isolation.
- Contract tests: Test interactions between components and verify API contracts are fulfilled.
- API tests: Test the external API endpoints (under
/api/v1/). - App tests: Test the web application API endpoints (under
/api/).
- API tests: Test the external API endpoints (under
- Smoke tests: Basic tests to verify that the application runs correctly.
API vs App Endpoints
Plane has two types of API endpoints:
-
External API (
plane.api):- Available at
/api/v1/endpoint - Uses API key authentication (X-Api-Key header)
- Designed for external API contracts and third-party access
- Tests use the
api_key_clientfixture for authentication - Test files are in
contract/api/
- Available at
-
Web App API (
plane.app):- Available at
/api/endpoint - Uses session-based authentication (CSRF disabled)
- Designed for the web application frontend
- Tests use the
session_clientfixture for authentication - Test files are in
contract/app/
- Available at
Running Tests
To run all tests:
python -m pytest
To run specific test categories:
# Run unit tests
python -m pytest plane/tests/unit/
# Run API contract tests
python -m pytest plane/tests/contract/api/
# Run App contract tests
python -m pytest plane/tests/contract/app/
# Run smoke tests
python -m pytest plane/tests/smoke/
For convenience, we also provide a helper script:
# Run all tests
./run_tests.py
# Run only unit tests
./run_tests.py -u
# Run contract tests with coverage report
./run_tests.py -c -o
# Run tests in parallel
./run_tests.py -p
Fixtures
The following fixtures are available for testing:
api_client: Unauthenticated API clientcreate_user: Creates a test userapi_token: API token for the test userapi_key_client: API client with API key authentication (for external API tests)session_client: API client with session authentication (for app API tests)plane_server: Live Django test server for HTTP-based smoke tests
Writing Tests
When writing tests, follow these guidelines:
- Place tests in the appropriate directory based on their type.
- Use the correct client fixture based on the API being tested:
- For external API (
/api/v1/), useapi_key_client - For web app API (
/api/), usesession_client - For smoke tests with real HTTP, use
plane_server
- For external API (
- Use the correct URL namespace when reverse-resolving URLs:
- For external API, use
reverse("api:endpoint_name") - For web app API, use
reverse("endpoint_name")
- For external API, use
- Add the
@pytest.mark.django_dbdecorator to tests that interact with the database. - Add the appropriate markers (
@pytest.mark.contract, etc.) to categorize tests.
Test Fixtures
Common fixtures are defined in:
conftest.py: General fixtures for authentication, database access, etc.conftest_external.py: Fixtures for external services (Redis, Elasticsearch, Celery, MongoDB)factories.py: Test factories for easy model instance creation
Best Practices
When writing tests, follow these guidelines:
- Use pytest's assert syntax instead of Django's
self.assert*methods. - Add markers to categorize tests:
@pytest.mark.unit @pytest.mark.contract @pytest.mark.smoke - Use fixtures instead of setUp/tearDown methods for cleaner, more reusable test code.
- Mock external dependencies with the provided fixtures to avoid external service dependencies.
- Write focused tests that verify one specific behavior or edge case.
- Keep test files small and organized by logical components or endpoints.
- Target 90% code coverage for models, serializers, and business logic.
External Dependencies
Tests for components that interact with external services should:
- Use the
mock_redis,mock_elasticsearch,mock_mongodb, andmock_celeryfixtures for unit and most contract tests. - For more comprehensive contract tests, use Docker-based test containers (optional).
Coverage Reports
Generate a coverage report with:
python -m pytest --cov=plane --cov-report=term --cov-report=html
This creates an HTML report in the htmlcov/ directory.
Migration from Old Tests
Some tests are still in the old format in the api/ directory. These need to be migrated to the new contract test structure in the appropriate directories.