fix(api): fix schema for Imports Create to support XLS/base64 library upload payload DEV-2189

[Guitlle]

🗒️ Checklist

1. run linter locally
2. update developer docs (API, README, inline, etc.), if any
3. for user-facing doc changes create a Zulip thread at #Support Docs Updates, if any
4. draft PR with a title <type>(<scope>)<!>: <title> DEV-1234
5. assign yourself, tag PR: at least Front end and/or Back end or workflow
6. fill in the template below and delete template comments
7. review thyself: read the diff and repro the preview as written
8. open PR & confirm that CI passes & request reviewers, if needed
9. act on any greptile review below a 5/5 score or leave comment explaining why you won't
10. delete this checklist section from the final squash commit before merging

📣 Summary

Fixed the ImportCreateRequestSerializer schema definition to include the missing fields base64Encoded, library, desired_type, totalFiles. The OpenAPI and Orval output files were updated to reflect this change.

[greptile-apps]

Greptile Summary

This PR adds the previously missing fields (base64Encoded, library, desired_type, totalFiles, file) to the ImportCreateRequestSerializer schema definition, removes the incorrectly enforced required constraint on the whole request body and its individual fields, and regenerates the OpenAPI YAML/JSON snapshots and Orval-generated TypeScript.

• All formerly required fields (destination, url, assetUid) are now optional/nullable, matching the real conditional logic in the view where only one of base64Encoded, file, or url is needed per request.
• The new file field in the OpenAPI schema is set to format: uri rather than the correct format: binary for multipart file uploads. This error propagates into the Orval-generated TypeScript type (string | null instead of Blob | null) and the client's FormData serialization, making the direct binary file upload code path non-functional through the generated client.

Confidence Score: 4/5

The base64Encoded upload path works correctly; the direct binary file upload path is broken in the generated client due to the wrong OpenAPI format.

The file field in both OpenAPI snapshots declares format: uri instead of format: binary. This causes Orval to emit file?: string | null in the TypeScript model, so the generated client serializes the field as a plain string in FormData. The server view calls request.data['file'].read(), which will raise AttributeError on a string — meaning any caller relying on the generated client to upload a file via that code path will fail at runtime.

static/openapi/schema_v2.yaml and static/openapi/schema_v2.json — the file field needs format: binary (not format: uri), followed by regeneration of jsapp/js/api/models/importCreateRequest.ts and jsapp/js/api/react-query/manage-projects-and-library-content.ts.

Sequence Diagram

sequenceDiagram
    participant Client as TypeScript Client
    participant Server as Django View

    Note over Client: importCreateRequest.file = "some-string"
    Client->>Client: formData.append("file", importCreateRequest.file)
    Note over Client: ❌ Sends string, not binary

    Client->>Server: POST /api/v2/imports/ (multipart/form-data)

    Server->>Server: if 'base64Encoded' in request.POST → OK ✅
    Server->>Server: elif 'file' in request.data → request.data['file'].read()
    Note over Server: ❌ AttributeError: 'str' object has no attribute 'read'

    Note left of Client: Root cause: OpenAPI schema declares file as format:uri
    Note left of Client: should be format:binary → Orval generates string not Blob/File

Loading

_{Reviews (2): Last reviewed commit: "add missing file field" | Re-trigger Greptile}

[greptile-apps]

Naming inconsistency: snake_case desired_type among camelCase fields

All other fields in this serializer use camelCase (base64Encoded, assetUid, totalFiles), but desired_type remains in snake_case. This inconsistency is now surfaced in the OpenAPI spec and in the generated TypeScript model. The view reads it as request.POST.get('desired_type', None), so the wire name must match — but it's worth confirming whether the intended public API name should be desiredType (camelCase) and the view updated to match, or if the inconsistency is intentional.

[Guitlle]

@noliveleger I think it'd be the other way around, we'd have to convert the camel case names to snake case because that's how we do it in the rest of the API fields. What do you think? Should we leave it as is?