Skip to content
This repository was archived by the owner on Jun 2, 2020. It is now read-only.

Support async/await in user functions #270

Closed
peterhuene opened this issue May 15, 2019 · 4 comments
Closed

Support async/await in user functions #270

peterhuene opened this issue May 15, 2019 · 4 comments
Assignees
@peterhuene
Labels
enhancement New feature or request
Milestone
0.10.0

Comments

@peterhuene
Copy link
Owner

peterhuene commented May 15, 2019 •
edited
Loading

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 than rpc::InvocationResponse.

A continuation will need to be added that sends the ready response back to the functions host.
@peterhuene peterhuene added the enhancement New feature or request label May 15, 2019
@peterhuene peterhuene added this to the 0.9.0 milestone May 15, 2019
@peterhuene peterhuene self-assigned this May 15, 2019
@peterhuene peterhuene added the in progress Work is in progress label May 15, 2019
@peterhuene
Copy link
Owner Author

One big problem already encountered: the TLS used to store the function name and invocation id, which is used when the function uses the log crate (or if it panics) to associate the log message with the invocation, can't be used since we don't know what thread the executor will spawn the task on. See rustasync/team#7 for some ideas.

@peterhuene
Copy link
Owner Author

peterhuene commented May 15, 2019 •
edited
Loading

While std::future::Future has been stabilized, the stable Rust containing it isn't released yet. So, we'll need to wait a few weeks until it does, otherwise there will be a lot of additional conditional code.

@peterhuene peterhuene added blocked Issue is currently blocked. and removed in progress Work is in progress labels May 17, 2019
@peterhuene
Copy link
Owner Author

Marking blocked on tower-grpc being released since I don't want to implement this before then.

@peterhuene peterhuene modified the milestones: 0.9.0, 0.10.0 Jun 11, 2019
@peterhuene peterhuene added in progress Work is in progress and removed blocked Issue is currently blocked. labels Jun 11, 2019
@peterhuene
Copy link
Owner Author

Marking dependent on tokio-rs/tokio#1120.

peterhuene pushed a commit that referenced this issue Jul 8, 2019
Implement async Azure Functions.
57696c0 
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
Implement async Azure Functions.
814bbbc 
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 peterhuene mentioned this issue Jul 8, 2019
Merged
@peterhuene 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
Implement async Azure Functions.
d329c54 
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 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 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.
Assignees

@peterhuene peterhuene

Labels
enhancement New feature or request
Projects
None yet
Milestone
0.10.0
Development

No branches or pull requests
1 participant
@peterhuene