Spike: Translation Workflow Limits With Long Assets

[monsieurBoutte]

Spike: Translation Workflow Limits With Long Assets

Summary

We need to understand how the translation function behaves with much longer and larger media assets than the ones we use in current tests. The expectation is that at some duration or size the workflow will start to fail or hit provider limits. This spike explores those limits and documents options to mitigate them.

Goals

• Identify practical duration and size limits for translation requests with the current provider configuration.
• Observe how failures surface (errors, timeouts, partial results).
• Collect data to inform follow up work such as chunking, batching, or alternative workflows.

Questions to Answer

• At what duration and file size do we start seeing errors or timeouts for translation calls
• Are failures deterministic or dependent on content characteristics
• What limits are enforced by the provider vs our own infrastructure
• Do we need guardrails in the SDK API to prevent obviously invalid requests

Proposed Work

• Create a set of test assets that scale up in:
  • Duration (for example 30 minutes, 60 minutes, 90 minutes and above)
  • File size and bitrate
• Run manual or scripted translation calls for each asset and record:
  • Success or failure
  • Error messages and status codes where applicable
  • Latency and resource usage trends
• Summarize findings and propose follow up work if needed:
  • Hard limits or validations in the SDK
  • Chunked request workflow
  • Streaming or staged processing

Deliverable

• Short writeup in the repo or internal docs summarizing:
  • Tested scenarios
  • Observed limits and failure modes
  • Recommended next steps for hardening the translation workflow