refactor(file_uploads): implement proper Tower layer and fix HTTP client buffering

[BrynCooke]

Task

Refactor file uploads plugin from a temporary function-based approach to a proper Tower layer implementation, and resolve HTTP client service buffering issues that were causing runtime panics.

Why This Change Is Needed

The file uploads functionality was implemented as a temporary solution using direct function calls (http_request_wrapper) in the subgraph service, which violated Tower service architecture principles and created technical debt. Additionally, the HTTP client service buffering was causing poll_ready panics due to improper Tower service call patterns.

Key issues resolved:

• Runtime panics: `send_item` called without first calling `poll_reserve`
• Technical debt from temporary file upload implementation
• Architectural inconsistency with other router plugins
• Improper Tower service buffering patterns

How It Was Tackled

Layer Implementation

• Created FileUploadLayer and FileUploadService following established Tower patterns
• Implemented proper http_client_service method in FileUploadsPlugin
• Removed temporary http_request_wrapper function call from subgraph service
• Eliminated acknowledged TODO about temporary solution

Service Buffering Fixes

• Switched from .buffer(DEFAULT_BUFFER_SIZE) to .buffered() for proper Clone handling
• Updated do_fetch to use .oneshot() instead of .call() for correct Tower semantics
• Fixed lint issues (unused imports, unnecessary mut parameters)

Technical Details

Tower Service Patterns

• FileUploadService implements proper Tower Service trait with async request transformation
• Uses standard plugin layer composition with ServiceBuilder
• Maintains all existing multipart form data processing functionality

HTTP Client Service Buffering

• .buffered() uses router's ServiceBuilderExt which handles Clone requirements correctly
• .oneshot() ensures proper poll_ready/call sequencing in Tower services
• HTTP client services require different buffering patterns than router/supergraph services

Current Limitation

Note: The HTTP client service is currently recreated for each request rather than being cached like other services. This will be addressed in a separate PR to implement proper caching at the factory level.

Review Strategy

Architecture Review

• Verify the FileUploadLayer follows established plugin patterns
• Confirm removal of temporary solution doesn't break functionality
• Check that Tower service composition is correct

Testing Focus

• Verify multipart form data processing works across different subgraphs
• Confirm no regressions in subgraph request handling

---

Checklist

Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.

• [ ] Changes are compatible[^1]
• [ ] Documentation[^2] completed
• [ ] Performance impact assessed and acceptable
• [ ] Metrics and logs are added[^3] and documented
• Tests added and passing[^4]
  • [ ] Unit Tests
  • [ ] Integration Tests
  • [ ] Manual Tests

Exceptions

Note any exceptions here

Notes

[^1]: It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. [^2]: Configuration is an important part of many changes. Where applicable please try to document configuration examples. [^3]: A lot of (if not most) features benefit from built-in observability and debug-level logs. Please read this guidance on metrics best-practices. [^4]: Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions.

[github-actions[bot]]

@BrynCooke, please consider creating a changeset entry in /.changesets/. These instructions describe the process and tooling.

[apollo-librarian[bot]]

✅ Docs preview has no changes

The preview was not built because there were no changes.

Build ID: 10f7051675dbdcd60dd1158a