sie

This occurs because sie-server batches long-form Whisper requests, but Transformers' pipeline collate cannot handle log-mel tensors with different frame counts, such as [128, 18110] and [128, 18593]. It affects sie-server 0.9.0 with transformers 4.57.6 when two recordings longer than 30 seconds are processed in the same batch.

Immediate workaround: set Whisper pipeline_batch_size to 1 in the server configuration and restart the server. This processes each recording separately and avoids the failing collate path. Clips of 30 seconds or shorter are unaffected.

Permanent fix: in packages/sie_server/src/sie_server/adapters/whisper/adapter.py, keep batch_size=self._pipeline_batch_size for the short-form group, but run the long-form group with batch_size=1, one recording per pipeline call. For direct Transformers usage, call the pipeline separately for each long-form audio item instead of passing multiple unequal-length items in one batch.

After the fix, two recordings longer than 30 seconds with different durations should return transcripts in one extract() call, and concurrency 4/8 should complete without HTTP 500. Measured long-form throughput remains effectively unchanged: about 21.9 audio-seconds/second at concurrency 4 with batch_size=1 versus 22.3 at concurrency 1 with the default configuration.

Upgrade to a sie_mcp release containing PR #292 (commit f5c4451). As an immediate workaround, explicitly pin the public origin so X-Forwarded-Host and X-Forwarded-Proto are ignored:

export SIE_MCP_PUBLIC_URL=https://mcp.your-domain.example

For Helm, set:

mcpEdge:
  publicUrl: "https://mcp.your-domain.example"
  oauthEnabled: true

After the fix, if SIE_MCP_PUBLIC_URL is unset, request-origin derivation is allowed only for loopback hosts or hosts listed in SIE_MCP_ALLOWED_HOSTS; untrusted hosts receive HTTP 503 from OAuth metadata routes and no WWW-Authenticate challenge. The updated Helm chart also renders SIE_MCP_PUBLIC_URL=https://<mcpEdge.ingress.host> automatically when mcpEdge.publicUrl is empty and edge ingress is enabled. Ensure your reverse proxy or load balancer overwrites/sanitizes X-Forwarded-Host, and do not enable ingress-nginx use-forwarded-headers unless those headers are trusted.

This happened because the image builders ran resolve-deps to write each bundle's ranged dependency specifiers (e.g. gliner>=0.2.26,<1) to a requirements file, then ran pip install --target=/app/bundle-libs -r, which resolved ranges to the newest PyPI release at build time, shadowing the versions pinned in uv.lock that CI tests against. Two builds of the same commit could therefore ship different versions. Fixed by PRs #653 and #802: bundle images no longer resolve ranges during the build. Instead they install a saved dependency closure from checked-in per-target lock files. The 15 checked-in target locks cover all 11 released Linux amd64 images plus the four supported CPU arm64 combinations. Packages keep their root uv.lock pins unless an explicit, documented bundle exception applies (e.g. the transformers 5 bundle). CI rejects stale or inconsistent locks, and image builds verify and retain the installed /app/bundle-libs inventory (resolved pip freeze) so any deployed version can be audited. Upgrading to a release containing these fixes makes builds reproducible: building the same commit twice now installs identical versions.

This occurs in chart 0.7.2 because the keda-apply hook has a hardcoded 256Mi memory limit. Upgrades fetch existing ScaledObject resources as JSON and process them with jq, using more memory than a fresh install. Upgrade to a chart version containing PR #268, which adds configurable hook resources and raises the default limit to 1Gi. Then set, for example:

hooks:
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 200m
      memory: 1Gi

Apply the values with helm upgrade <release> <chart> -f values.yaml. The configurable resources apply to the keda-apply, keda-cleanup, and KEDA ready hook Jobs. As a temporary workaround on older charts, you can set upgrade.disableHooks: true, but this is not recommended because it skips ScaledObject reconciliation and health checks. Helm post-renderers cannot be used to patch hook Jobs.

Upgrade to a release containing the fix fix(server): report measured embedding token usage (the fix for issue #566). On the single-node OpenAI-compatible route, the server now passes pipeline timing/usage through so that usage.prompt_tokens and usage.total_tokens use the worker's exact post-tokenization count when available. If no measured count exists, it falls back to the previous character estimate (len(input) / 4, minimum 1) because OpenAI clients expect a usage object. The response also includes usage.sie_token_source, set to worker for measured counts or character_estimate for the fallback. As a workaround before upgrading, use the native POST /v1/encode/{model} endpoint for exact counts, or place the service behind the gateway, which already reports sie_token_source as worker or character_estimate.