Don't write files during multipart processing in TinyGo #399
Conversation
Codecov ReportBase: 77.13% // Head: 77.12% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## v3/dev #399 +/- ##
==========================================
- Coverage 77.13% 77.12% -0.02%
==========================================
Files 137 137
Lines 5975 5985 +10
==========================================
+ Hits 4609 4616 +7
- Misses 1100 1102 +2
- Partials 266 267 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
|
Actually will investigate some more, one test passes and the next crashes, will see what's going on |
transaction.go
Outdated
| for _, name := range tx.Variables.Files.Get("") { | ||
| // TODO we kind of assume file_size is always populated with the name at index 0. | ||
| // Instead perhaps we need to have a collection of structs rather than multiple collections. | ||
| size, _ := strconv.ParseInt(tx.Variables.FilesSizes.Get(name)[0], 10, 64) |
There was a problem hiding this comment.
Found this bug when running ftw with wasm, after fixing the above :)
| if err != nil { | ||
| return err | ||
| var size int64 | ||
| if !environment.IsTinyGo { |
There was a problem hiding this comment.
nit: can you do first the negative to save one negation?
There was a problem hiding this comment.
Sorry JC I missed this comment - I can followup with the change if you feel strongly about it. I've generally wanted to keep "normal code" first, and TinyGo code later in order where possible
|
Curious about this change, I was wondering if |
|
I think the multipart processor should be optimized. Keep in mind that the size of the reader is not greater than the request body memory limit (about 100kb) Maybe in the case of tinygo we should handle the body in memory? rather than discarding it? |
Since it is single thread and the body has a limit we could handle it in memory, what do you think @anuraaga? |
|
The code works fine in wasm, envoy stubs out a subset of fs APIs and this seems to only hit those. Yeah I thought of handling in-memory for wasm case, but it looked like it would take some reasonable work. Can we do it in a separate PR to first fix failure on just filename rules that happens right now? |
|
Yeah I think it makes sense to do in a separate PR to keep the scope small. |
anuraaga
force-pushed
the
no-multipart-writefile
branch
from
e990f9c
to
e7dadcc
Compare
No description provided.