descompactar arquivos no S3 falhar, não sei por que

(novas informações abaixo) Estou tentando configurar uma função lambda que reage aos arquivos tgz enviados, descompactando-os e gravando os resultados novamente no S3. O descompactar e descompactar funcionam bem, mas o upload para o S3 falha:

/Users/russell/lambda/gzip/node_modules/aws-sdk/lib/s3/managed_upload.js:350
    var buf = self.body.read(self.partSize - self.partBuffer.length) ||
                        ^
TypeError: undefined is not a function
    at ManagedUpload.fillStream (/Users/russell/lambda/gzip/node_modules/aws-sdk/lib/s3/managed_upload.js:350:25)
    at Entry.<anonymous> (/Users/russell/lambda/gzip/node_modules/aws-sdk/lib/s3/managed_upload.js:167:28)
    at Entry.emit (events.js:104:17)
    at Entry._read (/Users/russell/lambda/gzip/node_modules/tar/lib/entry.js:123:12)
    at Entry.end (/Users/russell/lambda/gzip/node_modules/tar/lib/entry.js:82:8)
    at Parse._process (/Users/russell/lambda/gzip/node_modules/tar/lib/parse.js:107:13)
    at BlockStream.<anonymous> (/Users/russell/lambda/gzip/node_modules/tar/lib/parse.js:47:8)
  ,  at BlockStream.emit (events.js:107:17)
    at BlockStream._emitChunk (/Users/russell/lambda/gzip/node_modules/tar/node_modules/block-stream/block-stream.js:145:10)
    at BlockStream.write (/Users/russell/lambda/gzip/node_modules/tar/node_modules/block-stream/block-stream.js:45:10)

Esse erro ocorre quando eu escrevo no S3, mas se eu gravar os arquivos localmente no disco, ele funcionará, portanto, o pipeline estará correto.

Aqui está o código que demonstra o problema:

var aws = require('aws-sdk');
var s3 = new aws.S3({apiVersion: '2006-03-01'});
var zlib = require('zlib');
var tar = require('tar');
var fstream = require('fstream');

fstream.Reader({'path': 'testdata.tar.gz'})
    .pipe(zlib.Unzip())
    .pipe(tar.Parse())
    .on('entry', function(entry) {
        var filename = entry.path;
        console.log('got ' + entry.type + ' ' + filename);
        if (entry.type == 'File') {
            if (1) { // switch between working and nonworking cases
                s3.upload({Bucket: 'my_bucket', Key: 'gunzip-test/' + filename, Body: entry}, {},
                          function(err, data) {
                              if (err) 
                                  console.log('ERROR!');
                              else
                                  console.log('OK');
                          });
            }
            else {
                entry.pipe(fstream.Writer({ 'path': '/tmp/mytest/' + filename }));
            }
        }
    });

Se o código estiver definido para gravar no S3, ele falhará com o erro acima, se gravar os arquivos extraídos localmente, será bem-sucedido. ENTRY é um fluxo e, de acordo com o documento, deve ser aceito no parâmetro Body de upload. Coloquei uma declaração de impressão no ManagedUpload, onde ocorre a falha, e confirmei que self.body é um fluxo:

var stream = require('stream');
console.log('is it a stream? ' + ((self.body instanceof stream) ? 'yes' : 'no'));
console.log('self.body.read is ' + self.body.read);

retorna

$ got File gunzip.js
is it a stream? yes
self.body.read is undefined

Sou bastante novo com aws e node.js, portanto, pode haver um problema básico com isso, mas passei um dia e não o encontrei. Fiz a chamada de upload com descompacte em vez de gzip e funcionou (usando funções lambda para descompactar arquivos no S3 é realmente sloooooow) Alguém pode me apontar algo que estou fazendo de errado neste código?

obrigado

Eu acho que entendo isso um pouco melhor. Eu quebrei o oleoduto em pedaços e olhei para cada um. O problema é que o tar.Parse usa fstream e não stream. Se eu olhar para o retorno da instrução .pipe (tar.Parse ()), é um fluxo, mas não é um fluxo.Regível ou um fluxo.Writable. O fstream não define um método read () (seu leitor é baseado no Stream, não é um stream.Readable); portanto, o tar.Parse, que é baseado no Stream, também não possui um.

Portanto, um refinamento da questão é: isso é um bug no fstream ou o fstream não pretende ser um fluxo? Eu acho que é um bug - do README:

"Como fluxos FS, mas com stat neles, e diretórios de suporte e links simbólicos, além de arquivos normais. Além disso, você pode usar isso para definir as estatísticas em um arquivo, mesmo se você não alterar o conteúdo ou para criar um link simbólico etc. "

questionAnswers(2)

yourAnswerToTheQuestion