dragonflight/services/worker/src/s3/client.js

97 lines
2.8 KiB
JavaScript
Raw Normal View History

2026-04-07 21:58:20 -04:00
import { S3Client, GetObjectCommand, PutObjectCommand } from '@aws-sdk/client-s3';
import { createReadStream, createWriteStream } from 'fs';
fix(player): stitch S3 ranges around RustFS empty-body bug (#143) RustFS returns empty bodies for ranged GETs whose start offset is past ~5.9 MB on single-file proxy MP4s. HEAD reports correct size, full GET (`bytes=0-`) works, but `bytes=8179166-` comes back 206 + correct Content-Range header with zero bytes. Confirmed via direct S3 probe against broadcastmgmt.cloud/dragonmam (see scratch tests). Workaround in mam-api `GET /api/v1/assets/:id/video` until the proxy worker emits HLS (planned v1.2.1): - HEAD the object first to learn total size (also gives ETag / Last-Modified for conditional requests). - No-Range / unparseable-Range / pre-EOF requests \u2192 plain pipe. - Parsed `bytes=N-M` requests below RUSTFS_RANGE_SAFE_START (default 5_500_000) \u2192 direct ranged GET, RustFS handles fine. - Anything reaching into the broken zone \u2192 stream from offset 0, drop bytes below start, stop at end. Memory stays flat; extra bandwidth = (end+1 - requested-size) per seek. - Genuinely out-of-range \u2192 416 with Cache-Control: no-store so the browser doesn't poison its cache. Also stashes (not yet wired up) the HLS pieces we'll need for the follow-up: `segmentToHls` ffmpeg helper + `uploadDirectoryToS3` worker s3 helper. Harmless additions; not referenced by any code path yet. Confirmed against the affected asset (a72aaa03-...): bytes=0-100k + 50% +100k native pass-through; 70% +100k and near-EOF previously hung the browser, now stream correctly via the stitched path. Refs #143.
2026-05-26 22:38:42 -04:00
import { readdir } from 'fs/promises';
import { join, extname } from 'path';
2026-04-07 21:58:20 -04:00
import { pipeline } from 'stream/promises';
fix(player): stitch S3 ranges around RustFS empty-body bug (#143) RustFS returns empty bodies for ranged GETs whose start offset is past ~5.9 MB on single-file proxy MP4s. HEAD reports correct size, full GET (`bytes=0-`) works, but `bytes=8179166-` comes back 206 + correct Content-Range header with zero bytes. Confirmed via direct S3 probe against broadcastmgmt.cloud/dragonmam (see scratch tests). Workaround in mam-api `GET /api/v1/assets/:id/video` until the proxy worker emits HLS (planned v1.2.1): - HEAD the object first to learn total size (also gives ETag / Last-Modified for conditional requests). - No-Range / unparseable-Range / pre-EOF requests \u2192 plain pipe. - Parsed `bytes=N-M` requests below RUSTFS_RANGE_SAFE_START (default 5_500_000) \u2192 direct ranged GET, RustFS handles fine. - Anything reaching into the broken zone \u2192 stream from offset 0, drop bytes below start, stop at end. Memory stays flat; extra bandwidth = (end+1 - requested-size) per seek. - Genuinely out-of-range \u2192 416 with Cache-Control: no-store so the browser doesn't poison its cache. Also stashes (not yet wired up) the HLS pieces we'll need for the follow-up: `segmentToHls` ffmpeg helper + `uploadDirectoryToS3` worker s3 helper. Harmless additions; not referenced by any code path yet. Confirmed against the affected asset (a72aaa03-...): bytes=0-100k + 50% +100k native pass-through; 70% +100k and near-EOF previously hung the browser, now stream correctly via the stitched path. Refs #143.
2026-05-26 22:38:42 -04:00
const CONTENT_TYPES = {
'.m3u8': 'application/vnd.apple.mpegurl',
'.m4s': 'video/iso.segment',
'.mp4': 'video/mp4',
};
2026-04-07 21:58:20 -04:00
const createS3Client = () => {
return new S3Client({
region: process.env.S3_REGION || 'us-east-1',
2026-04-07 21:58:20 -04:00
endpoint: process.env.S3_ENDPOINT,
credentials: {
accessKeyId: process.env.S3_ACCESS_KEY,
secretAccessKey: process.env.S3_SECRET_KEY,
2026-04-07 21:58:20 -04:00
},
forcePathStyle: true,
});
};
export const downloadFromS3 = async (bucket, key, localPath) => {
const client = createS3Client();
try {
const response = await client.send(
new GetObjectCommand({ Bucket: bucket, Key: key })
);
const writeStream = createWriteStream(localPath);
await pipeline(response.Body, writeStream);
} finally {
client.destroy();
}
};
export const uploadToS3 = async (bucket, key, localPath) => {
const client = createS3Client();
try {
const readStream = createReadStream(localPath);
await client.send(
new PutObjectCommand({
Bucket: bucket,
Key: key,
Body: readStream,
})
);
} finally {
client.destroy();
}
};
fix(player): stitch S3 ranges around RustFS empty-body bug (#143) RustFS returns empty bodies for ranged GETs whose start offset is past ~5.9 MB on single-file proxy MP4s. HEAD reports correct size, full GET (`bytes=0-`) works, but `bytes=8179166-` comes back 206 + correct Content-Range header with zero bytes. Confirmed via direct S3 probe against broadcastmgmt.cloud/dragonmam (see scratch tests). Workaround in mam-api `GET /api/v1/assets/:id/video` until the proxy worker emits HLS (planned v1.2.1): - HEAD the object first to learn total size (also gives ETag / Last-Modified for conditional requests). - No-Range / unparseable-Range / pre-EOF requests \u2192 plain pipe. - Parsed `bytes=N-M` requests below RUSTFS_RANGE_SAFE_START (default 5_500_000) \u2192 direct ranged GET, RustFS handles fine. - Anything reaching into the broken zone \u2192 stream from offset 0, drop bytes below start, stop at end. Memory stays flat; extra bandwidth = (end+1 - requested-size) per seek. - Genuinely out-of-range \u2192 416 with Cache-Control: no-store so the browser doesn't poison its cache. Also stashes (not yet wired up) the HLS pieces we'll need for the follow-up: `segmentToHls` ffmpeg helper + `uploadDirectoryToS3` worker s3 helper. Harmless additions; not referenced by any code path yet. Confirmed against the affected asset (a72aaa03-...): bytes=0-100k + 50% +100k native pass-through; 70% +100k and near-EOF previously hung the browser, now stream correctly via the stitched path. Refs #143.
2026-05-26 22:38:42 -04:00
// Upload every file in `localDir` to `bucket` under `keyPrefix/`. Used for the
// HLS proxy output (init.mp4 + segment_*.m4s + playlist.m3u8). Each file goes
// up as its own PutObject so individual segments stay small and never trigger
// RustFS's broken byte-range path on large objects.
export const uploadDirectoryToS3 = async (bucket, keyPrefix, localDir) => {
const client = createS3Client();
try {
const entries = await readdir(localDir, { withFileTypes: true });
const files = entries.filter(e => e.isFile()).map(e => e.name);
for (const name of files) {
const ext = extname(name).toLowerCase();
const ct = CONTENT_TYPES[ext] || 'application/octet-stream';
await client.send(new PutObjectCommand({
Bucket: bucket,
Key: `${keyPrefix}/${name}`,
Body: createReadStream(join(localDir, name)),
ContentType: ct,
}));
}
return files;
} finally {
client.destroy();
}
};
// Multipart-aware streaming upload — used by the promotion worker to push
// large growing-file masters without buffering them entirely in memory.
export const uploadStreamToS3 = async (bucket, key, readable) => {
const { Upload } = await import('@aws-sdk/lib-storage');
const client = createS3Client();
try {
const upload = new Upload({
client,
params: { Bucket: bucket, Key: key, Body: readable },
queueSize: 4,
partSize: 8 * 1024 * 1024,
});
await upload.done();
} finally {
client.destroy();
}
};