Describe the bug

This oen works:

let foo = try FormDataDecoder().decode(Foo.self, from: data, boundary: "12345")

this one isn't working

let foo = try FormDataDecoder().decode(Foo?.self, from: data, boundary: "12345")

Error:

caught error: "typeMismatch(MultipartKit.OrderedDictionary<Swift.String, MultipartKit.MultipartFormData>, Swift.DecodingError.Context(codingPath: [], debugDescription: "expected single value but encountered dictionary", underlyingError: nil))"

To Reproduce

You can adjust func testFormDataDecoderW3() to see this behaviour

Expected behavior

Content should be decoded no matter if type is Foo.self or Foo?.self

Environment

Tested od mian branch

Adds support for async websocket routes and upgrading of existing requests.

D'oh I thought this was websocket kit 😆

@0xTim The base branch is your async-await branch, should we not just gather all async-await stuff in that branch?

Adds support for async websocket routes and upgrading of existing requests.

These should only be applied to the top level Package.swift (i.e. the one with the executable in it)

Adds support for async/await variants of various functions

Right, so as linked above jemalloc will slowly burn down freed memory over time, as the allocator is entered. A single request does not diagnose a leak. Try using the application consistently: I'd expect to see that long-term memory usage is flat.

@Lukasa currently I'm testing it with Docker on macOS, where the VM is limited to 2GB of RAM. The CPU usage of the container is below 0.0% thus it also should be idling.

@obliqueRotationMethod I tried to change it to 'libjemalloc-dev', but the behavior stays the same.

@gipfelen Try changing 'libjemalloc2' to 'libjemalloc-dev' in the Dockerfile. This night I also saw that my App started crashing again when using libjemalloc2. Have rebuild it with libjemalloc-dev this morning and RAM is looking fine again

Also, is the application fully idle? If so, this is a known behaviour of jemalloc: jemalloc/jemalloc#1398

How much RAM is present on your system?

I changed my https://github.com/gipfelen/vaporLinuxLeak such that it uses jemalloc instead of malloc. But after a single call of http://localhost:8080/hello it uses more than 800MB of RAM, and it doesn't get freed (even after 5min +).

I had a similar issue, memory use increased over time using Linux until the app crashed while the same code had no issues on macOS. I was able to solve this by implementing jemalloc in my container

Deployed my Vapor Docker Container on CloudFoundry with 1GB RAM allocated. Since last week I tested my code under production conditions, decoding an 15MB-ish JSON every hour and writing this data to an internal Fluent SQLite DB. I noticed that now over time more and more RAM was used until the container crashed. @Lukasa mentioned jemalloc, hence I googled a bit and found that some other communities had similar issues and overcame them by using this allocator. Using jemalloc my RAM is looking great, after 24hours at about 80MB used. Previously it would have crashed 3 times by now.

My Dockerfile: [...]

================================

Run image

================================

FROM swift:5.4-focal-slim

Make sure all system packages are up to date.

RUN export DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true &&
apt-get -q update && apt-get -q dist-upgrade -y && apt-get -y install libjemalloc2 && rm -r /var/lib/apt/lists/*

ENV LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so**

[...]

@marc-medley vapor new vapor_template_apiweb --template https://github.com/VaporExamplesLab/VaporApiWebTemplate should work

@lmcd In short absolutely not.

First, these APIs are additional and gated behind availability checks. This won't stop you using Vapor on older OSes and Vapor 4 will work just as before.

Second, async/await is the most important change in server-side Swift since it was open sourced. Holding off on adopting would be the death of Vapor as people want to migrate to it and will choose other frameworks. We need to do what's best for the community as a whole and it's not feasible to hold back when the majority of users want and can use async/await

@rleconte the aim is to do this in Vapor 4

<!-- 🚀 Thank you for contributing! -->

<!-- Describe your changes clearly and use examples if possible. -->

<!-- When this PR is merged, the title and body will be --> <!-- used to generate a release automatically. -->

HTTP route handlers now have experimental support for the new async/await features in Swift 5.5. However, WebSockets miss this functionality.

This means, that non blocking work for websockets still requires the use of EventLoopFutures, that tends to lead to harder to read code.

Please also add a version of the RoutesBuilder .webSocket and WebSocket .onText methods that create/support an async context.

Is it worth holding off on this for now? I and others I know are using Vapor (client and server features) on Apple platforms in which several years of OS support are required.

Vapor adopting async/Swift concurrency features will prevent us from using the latest Vapor releases for another year or two.

See: https://forums.swift.org/t/will-swift-concurrency-deploy-back-to-older-oss/49370/160

As far as I understand, this PR adds async/await support, but doesn't remove the current way of doing things (much like in Apple own APIs, an async variant of APIs is added on top of existing ones). So Vapor would make the async APIs available if your current swift version is adequate, and not bother you if it is not.
But I may very well be completely wrong 😅

The thing I'm not sure to understand is if this will be merged into Vapor 4 in an upcoming minor version, of be merged in an upcoming Vapor 5 ? 🤔

With that being said, even if this comes as a breaking change in Vapor 5 and you need to have the new Swift version supporting concurrency to use it, I think it is fine, and people who want to deploy to older macOS versions can still use Vapor 4, and should not prevent people deploying on macOS 12, Linux (or in docker for that matter) to have these improvements as soon as possible rather than in a few years. Especially as Swift structured concurrency looks to be a pretty big improvement for server side swift.

Is your feature request related to a problem? Please describe. I'm try to set up a website with Events, for which the TimeZone of the Date does not matter. Right now, viewing from different timezones always shows different times. I've set the Website to always set UTC with the right date and then save it.

Describe the solution you'd like Setting the date via #date(date, "YYYY-mm-dd HH:mm", static) or #date(date, "YYYY-mm-dd HH:mm", TimeZone: 0) or similar

Describe alternatives you've considered I've tried to edit the Date on the Server before showing it on the website, but could not get it to work. I have an Event Model which gets passed as the model or even a model array.

Additional context Any ideas to work around that problem?

Thank you

thanks to @0xTim got it working by looking at the default DateFormatter link

@denis-ev Just don't tell Leaf to format the date string, format it yourself with DateFormatter, then pass it to Leaf.

Hey @mkll, Then I have to modify a model which would be a bit more of a hassle.

@0xTim gave the tip about creating a custom DateFormatter.

So I'm trying to set a custom leaf tag. I'm checking out the Example, but I'm not sure how to pass the date to it.

@denis-ev Just don't tell Leaf to format the date string, format it yourself with DateFormatter, then pass it to Leaf.

Is your feature request related to a problem? Please describe. I'm try to set up a website with Events, for which the TimeZone of the Date does not matter. Right now, viewing from different timezones always shows different times.

Describe the solution you'd like Setting the date via #date(date, "YYYY-mm-dd HH:mm", static) or #date(date, "YYYY-mm-dd HH:mm", TimeZone: 0) or similar

Describe alternatives you've considered I've tried to edit the Date on the Server before showing it on the website, but could not get it to work. I have an Event Model which gets passed as the model or even a model array.

Additional context Any ideas to work around that problem?

Thank you

<!-- 🚀 Thank you for contributing! --->

Describe the bug

struct Payload: Content {
    struct NestedPayload: Content {
        let name: String
        let age: Int
    }
    let nestedPayload: [NestedPayload]
}

let encoder = FormDataEncoder()
let encoded = try encoder.encode(Payload(nestedPayload: [.init(name: "abc", age: 10),
                                                         .init(name: "def", age: 20)]),
                                 boundary: "-")
let decoder = FormDataDecoder()
let decoded = try decoder.decode(Payload.self, from: encoded, boundary: "-")

got output [ WARNING ] Value required for key 'nestedPayload.0.age'.

Environment

<!-- We must know your exact environment or it is very difficult to help. --> <!-- Hint: use vapor --version in the root directory of your Vapor project. -->

• Vapor Framework version: 4.27.0
• Multipart-Kit Framework version: 4.2.1
• Vapor Toolbox version: 18.3.3
• OS version: Mac OS 11.3