- Spegnimento
- 11 agosto 2026 alle ore 16:21 UTC
- Autore
- kamo
- Impegno
- f1de4ec
Il backend ora scorre a 3 GiB, ma tre cose nel browser e il BFF fatto che irraggiungibile, ogni fatale da solo. Il proxy di upload ha fatto `await request.formData()`, ha tirato fuori il file e ricostruito un secondo FormData in avanti — l'intero caricamento nel mucchio di questo processo, due volte. Ora tubi il corpo direttamente con nodo:http, la stessa costruzione che il proxy di aggancio di chat utilizza già portare 3 GiB in produzione. nodo:http piuttosto che fetch perché undici applica un 300s intestazioni timeout per ogni richiesta, e un caricamento multi-gigabyte spende molto più tempo di quello sul filo prima di ConversionService — che hashes il file spooled prima di rispondere — può rispondere; con fetch, il proxy piuttosto che il prodotto deciderebbe la dimensione massima del file. computeBlake3(file) e computeSha3256(file) ogni file di chiamata.arrayBuffer(), e i caricatori li ha condotti in una promessa. tutto, quindi il file era completamente residente nella scheda TWICE a picco. Al vecchio 500MB di cappuccio che era già un gigabyte di memoria scheda; a 3 GiB è sei e la scheda muore prima un byte viene caricato. Sostituito con computeFileDigests, che cammina il file una volta in 4 fette MiB e alimenta entrambi i hasher dallo stesso pezzo — la memoria di picco è un pezzo a qualsiasi dimensione, specchio HashUtils.computeDigests sul server. Entrambi i digestori sono ancora calcolati perché il caricamento endpoint ricomputa e confronta entrambi; js-sha3 è puro JavaScript e domina il tempo, che è il prezzo del più forte controllo lato server, così hashing ora segnala i progressi piuttosto che seduta al 2% per minuti. MultiFileUploader non aveva alcun limite di dimensione affatto, quindi un oversize pick hashing minuti speso per guadagnare un fallimento opaco. La dimensione è ora controllata prima che qualcosa legga il file, e il file viene aggiunto nel fase di errore che nomina sia la sua dimensione e il limite.