Release 1.48.0 successfully blocks execution of method `try app.autoMigrate().wait()` about fluent-kit HOT 9 CLOSED

You are correct - if the EventLoopFuture-based API was broken by these changes, that is a real bug and needs to be addressed.

from fluent-kit.

If you're using .wait() with app.autoMigrate(), you're most likely using an outdated version of the app entrypoint. The configure() method is async by default in the current app template, allowing you to write try await app.autoMigrate(). The pregenerated PostgreSQL template - in particular the entrypoint.swift and configure.swift files - provides an example starting point. In general, except in very unusual cases, there should no longer be any need to use .wait() for anything. Even if there is no async version of a futures-based method, you can use the EventLoopFuture.get() helper to turn any future into an await-able expression.

This having been said, none of the changes made in 1.48.0 should have affected this. My guess would be that you were lucking into it working before and that the added Sendable annotations were enough to throw that off.

from fluent-kit.

@gwynne, My use of the legacy entry point is because I (surprise!) do not use Swift Structured Concurrency. My project did not start yesterday, it has been going on for more than three years, in the pre-async/await era, and it's relatively large, so it's hard to rewrite quickly.

In the same time, the SemVer principles tell us that without changing the major version, the API should not break. We see it breaking down, little by little, piece by piece, component by component. By updating dependencies today, I never know which one will break tomorrow. The major version remains the same.

We are gradually losing the ability to use the legacy API based on EventLoopFutures without any official announcement that it is no longer supported. But its support breaks down here and there, spontaneously.

This is not a complaint (although I am of course saddened by this state of affairs), it is simply a statement of the fact that, while formally remaining within the major version, Vapor is no longer quite version 4. This, in turn, means that upToNextMajor no longer works, and we should abandon it.

So, I'd like to know in advance if it's time to freeze the Vapor dependency versions as well as the version of itself, or if I can wait a little longer on this.

Thanks!

P.S. Since the situation is fully resolved, it would be better to close this issue.

from fluent-kit.

Can you see if #603 (and, ideally, vapor/fluent#774) fixes this issue? Easiest way to test is to temporarily add these lines to the dependencies for your app target in your Package.swift:

.package(url: "https://github.com/vapor/fluent-kit.git", branch: "oldstyle-migration-fix-maybe"),
.package(url: "https://github.com/vapor/fluent.git", branch: "sendable-fixup"),

If it doesn't work with both, try it with only the FluentKit override. (And don't forget to revert the change later!)

from fluent-kit.

@gwynne Yes it helped (with both)!

from fluent-kit.

Awesome, thanks for bearing with me on this! I'll make sure both PRs get merged and releases tagged ASAP.

from fluent-kit.

Wonderful!

from fluent-kit.

FluentKit 1.48.1 and Fluent 4.10.0 have been released, let me know if you run into any more issues!

from fluent-kit.

@gwynne I have already managed to rebuild the project with the new release and everything works. Thanks!

from fluent-kit.