This repository has been archived by the owner on Jun 2, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 25
Support async/await in user functions #270
Comments
One big problem already encountered: the TLS used to store the function name and invocation id, which is used when the function uses the |
While |
peterhuene
added
blocked
Issue is currently blocked.
and removed
in progress
Work is in progress
labels
May 17, 2019
Marking blocked on tower-grpc being released since I don't want to implement this before then. |
peterhuene
added
in progress
Work is in progress
and removed
blocked
Issue is currently blocked.
labels
Jun 11, 2019
Marking dependent on tokio-rs/tokio#1120. |
peterhuene
pushed a commit
that referenced
this issue
Jul 8, 2019
This commit implements support for async Azure Functions. The feature is behind the `unstable` feature for the azure-functions crate. Additionally, users must have a dependency on `futures-preview` for the generated code to build. Part of this work was refactoring the worker code out of the run command and into its own file. The thread-local invocation context also needed to be refactored to better support a futures-based invocation. Closes #270.
peterhuene
pushed a commit
that referenced
this issue
Jul 8, 2019
This commit implements support for async Azure Functions. The feature is behind the `unstable` feature for the azure-functions crate. Additionally, users must have a dependency on `futures-preview` for the generated code to build. Part of this work was refactoring the worker code out of the run command and into its own file. The thread-local invocation context also needed to be refactored to better support a futures-based invocation. This is a breaking change as `Context` is no longer a binding type; instead, users use `Context::current` to get the current invocation context. Closes #270.
peterhuene
added
pull request
A pull request exists for this issue.
and removed
in progress
Work is in progress
labels
Jul 8, 2019
peterhuene
pushed a commit
that referenced
this issue
Jul 8, 2019
This commit implements support for async Azure Functions. The feature is behind the `unstable` feature for the azure-functions crate. Additionally, users must have a dependency on `futures-preview` for the generated code to build. Part of this work was refactoring the worker code out of the run command and into its own file. The thread-local invocation context also needed to be refactored to better support a futures-based invocation. This is a breaking change as `Context` is no longer a binding type; instead, users use `Context::current` to get the current invocation context. Closes #270.
peterhuene
added
awaiting release
The issue has been resolved in the dev branch and is awaiting the next release to close.
and removed
pull request
A pull request exists for this issue.
labels
Jul 9, 2019
peterhuene
removed
the
awaiting release
The issue has been resolved in the dev branch and is awaiting the next release to close.
label
Nov 12, 2019
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Figure out a way to support async/await in Azure Functions for Rust.
This should be as natural as possible. Ideally, an
async
function with the#[func]
attribute should "just work".We'll need a different descriptor for async functions that returns a
Box<dyn Future<Output = rpc::InvocationResponse>>
rather thanrpc::InvocationResponse
.A continuation will need to be added that sends the ready response back to the functions host.
The text was updated successfully, but these errors were encountered: