[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8,"_9":10,"_11":12},"actionData","errors","root",{"_228":-5,"_231":232,"_233":234},"routes/shell",{"_41":42,"_227":-5,"_228":-5,"_229":230},"routes/repo",{"_34":-7,"_35":36,"_37":38,"_39":40,"_41":42,"_43":32,"_44":32,"_45":32,"_46":32,"_47":32,"_48":32,"_49":50,"_51":50,"_52":32,"_53":-7,"_54":-7,"_55":56,"_57":58,"_59":60,"_61":-5,"_62":63,"_64":65,"_66":67,"_68":69},"routes/repo.blob",{"_13":14,"_15":16,"_17":18,"_19":20,"_21":22,"_23":24,"_25":-5,"_26":27,"_28":29,"_29":30,"_31":32,"_33":14},"ref","main","path","evals/datasets/v2/proposals/rust-async-await.md","oid","5e6b11a01f150405563c41261a2121a60a59073b","size",23806,"commit","2182c95de44a8f63fd86af1c5874ae0ca298f807","mounts",[],"source","plain",{"_13":14,"_15":16},"kind","text","- Feature Name: async_await\n- Start Date: 2018-03-30\n- RFC PR: (leave this empty)\n- Rust Issue: (leave this empty)\n\n# Summary\n[summary]: #summary\n\nAdd async & await syntaxes to make it more ergonomic to write code manipulating\nfutures.\n\nThis has a companion RFC to add a small futures API to libstd and libcore.\n\n# Motivation\n[motivation]: #motivation\n\nHigh performance network services frequently use asynchronous IO, rather than\nblocking IO, becuase it can be easier to get optimal performance when handling\nmany concurrent connections. Rust has seen some adoption in the network\nservices space, and we wish to continue to enable those users - and to enable\nadoption by other users - by making it more ergonomic to write asynchronous\nnetwork services in Rust.\n\nThe development of asynchronous IO in Rust has gone through multiple phases.\nPrior to 1.0, we experimented with having a greenthreading runtime built into\nthe language. However, this proved too opinionated - because it impacted every\nprogram written in Rust - and it was removed shortly before 1.0. After 1.0,\nasynchronous IO initially focused around the mio library, which provided an\ncross-platform abstraction over the async IO primitives of Linux, Mac OS, and\nWindows. In mid-2016, the introduction of the futures crate had a major impact\nby providing a convenient, shared abstraction for asynchronous operations. The\ntokio library provided a mio-based event loop that could execute code\nimplemented using the futures interfaces.\n\nAfter gaining experience & user feedback with the futures-based ecosystem, we\ndiscovered certain ergonomics challenges. Using state which needs to be shared\nacross await points was extremely ergonomic - requiring either Arcs or join\nchaining - and while combinators were often more ergonomic than manually\nwriting a future, they still often led to messy sets of nested and chained\ncallbacks.\n\nFortunately, the Future abstraction is well suited to use with a syntactic\nsugar which has become common in many languages with async IO - the async and\nawait keywords. In brief, an asynchronous function returns a future, rather\nthan evaluating immediately when it is called. Inside the function, other\nfutures can be awaited using an await expression, which causes them to yield\ncontrol while the future is being polled. From a user's perspective, they can\nuse async/await as if it were synchronous code, and only need to annotate their\nfunctions and calls.\n\nAsync/await & futures can be a powerful abstraction for asynchronicity and\nconcurrency in general, and likely has applications outside of the asynchronous\nIO space. The use cases we've experience with today are generally tied to async\nIO, but by introducing first class syntax and libstd support we believe more\nuse cases for async & await will also flourish, that are not tied directly to\nasynchronous IO.\n\n# Guide-level explanation\n[guide-level-explanation]: #guide-level-explanation\n\n## Async functions\n\nFunctions can be annotated with the `async` keyword, making them \"async\nfunctions\":\n\n```rust\nasync fn function(argument: &str) -> usize {\n // ...\n}\n```\n\nAsync functions work differently from normal functions. When an async function\nis called, it does not enter the body immediately. Instead, it evaluates to an\nanonymous type which implements `Future`. As that future is polled, the\nfunction is evaluated up to the next `await` or return point inside of it (see\nthe await syntax section next).\n\nAn async function is a kind of delayed computation - nothing in the body of the\nfunction actually runs until you begin polling the future returned by the\nfunction. For example:\n\n```rust\nasync fn print_async() {\n println!(\"Hello from print_async\")\n}\n\nfn main() {\n let future = print_async();\n println!(\"Hello from main\");\n futures::block_on(future);\n}\n```\n\nThis will print `\"Hello from main\"` before printing `\"Hello from print_async\"`.\n\nAn `async fn foo(args..) -> T` is a function of the type\n`fn(args..) -> impl Future`. The return type is an anonymous type\ngenerated by the compiler.\n\n### `async ||` closures\n\nIn addition to functions, async can also be applied to closures. Like an async\nfunction, an async closure has a return type of `impl Future`, rather\nthan `T`. When you call that closure, it returns a future immediately without\nevaluating any of the body (just like an async function).\n\n```rust\nfn main() {\n let closure = async || {\n println(\"Hello from async closure.\");\n };\n println!(\"Hello from main\");\n let future = closure();\n println!(\"Hello from main again\");\n futures::block_on(future);\n}\n```\n\nThis will print both \"Hello from main\" statements before printing \"Hello from\nasync closure.\"\n\n## The `await!` compiler built-in\n\nA builtin called `await!` is added to the compiler. `await!` can be used to\n\"pause\" the computation of the future, yielding control back to the caller.\n`await!` takes any expression which implements `IntoFuture`, and evaluates to a\nvalue of the item type that that future has.\n\n```rust\n// future: impl Future\nlet n = await!(future);\n```\n\nThe expansion of await repeatedly calls `poll` on the future it receives,\nyielding control of the function when it returns `Async::Pending` and\neventually evaluating to the item value when it returns `Async::Ready`.\n\n`await!` can only be used inside of an async function or an async closure.\nUsing outside of that context is an error.\n\n(`await!` is a compiler built-in to leave space for deciding its exact syntax\nlater. See more information in the unresolved questions section.)\n\n# Reference-level explanation\n[reference-level-explanation]: #reference-level-explanation\n\n## Return type of `async` functions (and closures)\n\nThe return type of an async function is a unique anonymous type generated by\nthe compiler, similar to the type of a closure. You can think of this type as\nbeing like an enum, with one variant for every \"yield point\" of the function -\nthe beginning of it, the await expressions, and every return. Each variant\nstores the state that is needed to be stored to resume control from that yield\npoint.\n\nWhen the function is called, this anonymous type is returned in its initial\nstate, which contains all of the arguments to this function.\n\n### Trait bounds\n\nThe anonymous return type implements `Future`, with the return type as its\n`Item`. Polling it advances the state of the function, returning `Pending`\nwhen it hits an `await` point, and `Ready` with the item when it hits a\n`return` point. Any attempt to poll it after it has already returned Ready once\nwill panic.\n\nThe anonymous return type has a negative impl for the `Unpin` trait - that is\n`impl !Unpin`. This is because the future could have internal references which\nmeans it needs to never be moved.\n\n## Lifetime capture in the anonymous future\n\nAll of the input lifetimes to this function are captured in the future returned\nby the async function, because it stores all of the arguments to the function\nin its initial state (and possibly later states). That is, given a function\nlike this:\n\n```rust\nasync fn foo(arg: &str) -> usize { ... }\n```\n\nIt has an equivalent type signature to this:\n\n```rust\nfn foo<'a>(arg: &'a str) -> impl Future + 'a { ... }\n```\n\nThis is different from the default for `impl Trait`, which does not capture the\nlifetime. This is a big part of why the return type is `T` instead of `impl\nFuture`.\n\n### \"Initialization\" pattern\n\nOne pattern that sometimes occurs is that a future has an \"initialization\" step\nwhich could ideally happen before the future starts being polled. Because the\nasync function does not begin evaluating until you poll it, and it captures the\nlifetimes of its arguments, this pattern cannot be expressed with a single\n`async fn`.\n\nOne option is to write a function that returns `impl Future` using a closure\nwhich is evaluated immediately:\n\n```rust\n// only arg1's lifetime is captured in the returned future\nfn foo<'a>(arg1: &'a str, arg2: &str) -> impl Future + 'a {\n // do some initialization using arg2\n\n // closure which is evaluated immediately\n (async move || {\n // asynchronous portion of the function\n })()\n}\n```\n\nThe futures crate will provide an `async_block!` macro to make this cleaner:\n\n```rust\n// only arg1's lifetime is captured in the returned future\nfn foo<'a>(arg1: &'a str, arg2: &str) -> impl Future + 'a {\n // do some initialization using arg2\n\n // closure which is evaluated immediately\n async_block! {\n // asynchronous portion of the function\n }\n}\n```\n\n(Eventually, `async_block!` may be upgraded to a first class syntax, like\n`async { ... }`, but this is left as an unresolved question.)\n\n## The expansion of await\n\nThe `await!` builtin expands roughly to this:\n\n```rust\nlet mut future = IntoFuture::into_future($expression);\nlet mut pin = unsafe { Pin::new_unchecked(&mut future) };\nloop {\n match Future::poll(Pin::borrow(&mut pin), &mut ctx) {\n Async::Ready(item) => break item,\n Async::Pending => yield,\n }\t\n}\n```\n\nThis is not a literal expansion, because the `yield` concept cannot be\nexpressed in the surface syntax within `async` functions. This is why `await!`\nis a compiler builtin instead of an actual macro.\n\n# Drawbacks\n[drawbacks]: #drawbacks\n\nAdding async & await syntax to Rust is a major change to the language - easily\none of the most significant additions since 1.0. Though we have started with\nthe smallest beachhead of features, in the long term the set of features it\nimplies will grow as well (see the unresolved questions section). Such a\nsignificant addition mustn't be taken lightly, and only with strong motivation.\n\nWe believe that an ergonomic asynchronous IO solution is essential to Rust's\nsuccess as a language for writing high performance network services, one of our\ngoals for 2018. Async & await syntax based on the Future trait is the most\nexpedient & low risk path to achieving that goal in the near future.\n\nThis RFC, along with its companion lib RFC, makes a much firmer commitment to\nfutures & async/await than we have previously as a project. If we decide to\nreverse course after stabilizing these features, it will be quite costly.\nAdding an alternative mechanism for asynchronous programming would be more\ncostly because this exists. However, given our experience with futures, we are\nconfident that this is the correct path forward.\n\nThere are drawbacks to several of the smaller decisions we have made as well.\nThere is a trade off between using the \"inner\" return type and the \"outer\"\nreturn type, for example. We could have a different evaluation model for async\nfunctions in which they are evaluated immediately up to the first await point.\nThe decisions we made on each of these questions are justified in the\nappropriate section of the RFC.\n\n# Rationale and alternatives\n[alternatives]: #alternatives\n\nThis section contains alternative design decisions which this RFC rejects (as\nopposed to those it merely postpones).\n\n## The return type (`T` instead of `impl Future`)\n\nThe return type of an asynchronous function is a sort of complicated question.\nThere are two different perspectives on the return type of an async fn: the\n\"interior\" return type - the type that you return with the `return` keyword,\nand the \"exterior\" return type - the type that the function returns when you\ncall it.\n\nMost statically typed languages with async fns display the \"outer\" return type\nin the function signature. This RFC proposes instead to display the \"inner\"\nreturn type in the function signature. This has both advantages and\ndisadvantages.\n\n### The lifetime elision problem\n\nAs eluded to previously, the returned future captures all input lifetimes. By\ndefault, `impl Trait` does not capture any lifetimes. To accurately reflect the\nouter return type, it would become necessary to eliminate lifetime elision:\n\n```rust\nasync fn foo<'ret, 'a: 'ret, 'b: 'ret>(x: &'a i32, y: &'b i32) -> impl Future + 'ret {\n *x + *y\n}\n```\n\nThis would be very unergonomic and make async both much less pleasant to use\nand much less easy to learn. This issue weighs heavily in the decision to\nprefer returning the interior type.\n\nWe could have it return `impl Future` but have lifetime capture work\ndifferently for the return type of `async fn` than other functions; this seems\nworse than showing the interior type.\n\n### Polymorphic return (a non-factor for us)\n\nAccording to the C# developers, one of the major factors in returning `Task`\n(their \"outer type\") was that they wanted to have async functions which could\nreturn types other than `Task`. We do not have a compelling use case for this:\n\n1. In the 0.2 branch of futures, there is a distinction between `Future` and\n `StableFuture`. However, this distinction is artificial and only because\n object-safe custom self-types are not available on stable yet.\n2. The current `#[async]` macro has a `(boxed)` variant. We would prefer to\n have async functions always be unboxed and only box them explicitly at the\n call site. The motivation for the attribute variant was to support async\n methods in object-safe traits. This is a special case of supporting `impl\n Trait` in object-safe traits (probably by boxing the return type in the\n object case), a feature we want separately from async fn.\n3. It has been proposed that we support `async fn` which return streams.\n However, this mean that the semantics of the internal function would differ\n significantly between those which return futures and streams. As discussed\n in the unresolved questions section, a solution based on generators and\n async generators seems more promising.\n\nFor these reasons, we don't think there's a strong argument from polymorphism\nto return the outer type.\n\n### Learnability / documentation trade off\n\nThere are arguments from learnability in favor of both the outer and inner\nreturn type. One of the most compelling arguments in favor of the outer return\ntype is documentation: when you read automatically generated API docs, you will\ndefinitely see what you get as the caller. In contrast, it can be easier to\nunderstand how to write an async function using the inner return type, because\nof the correspondence between the return type and the type of the expressions\nyou `return`.\n\nRustdoc can handle async functions using the inner return type in a couple of\nways to make them easier to understand. At minimum we should make sure to\ninclude the `async` annotation in the documentation, so that users who\nunderstand async notation know that the function will return a future. We can\nalso perform other transformations, possibly optionally, to display the outer\nsignature of the function. Exactly how to handle API documentation for async\nfunctions is left as an unresolved question.\n\n## Built-in syntax instead of using macros in generators\n\nAnother alternative is to focus on stabilizing procedural macros and\ngenerators, rather than introducing built-in syntax for async functions. An\nasync function can be modeled as a generator which yields `()`.\n\nIn the long run, we believe we will want dedicated syntax for async functions,\nbecause it is more ergonomic & the use case is compelling and significant\nenough to justify it (similar to - for example - having built in for loops and\nif statements rather than having macros which compile to loops and match\nstatements). Given that, the only question is whether or not we could have a\nmore expedited stability by using generators for the time being than by\nintroducing async functions now.\n\nIt seems unlikely that using macros which expand to generators will result in a\nfaster stabilization. Generators can express a wider range of possibilities,\nand have a wider range of open questions - both syntactic and semantic. This\ndoes not even address the open questions of stabilizing more procedural macros.\nFor this reason, we believe it is more expedient to stabilize the minimal\nbuilt-in async/await functionality than to attempt to stabilize generators and\nproc macros.\n\n## `async` based on generators alone\n\nAnother alternative design would be to have async functions *be* the syntax for\ncreating generators. In this design, we would write a generator like this:\n\n```rust\nasync fn foo(arg: Arg) -> Return yield Yield\n```\n\nBoth return and yield would be optional, default to `()`. An async fn that\nyields `()` would implement `Future`, using a blanket impl. An async fn that\nreturns `()` would implement `Iterator`.\n\nThe problem with this approach is that does not ergonomically handle `Stream`s,\nwhich need to yield `Async`. It's unclear how `await` inside of an async fn\nyielding something other than `()` (which would include streams) would work.\nFor this reason, the \"matrix\" approach in which we have independent syntax for\ngenerator functions, async functions, and async generator functions, seems like\na more promising approach.\n\n## \"Hot async functions\"\n\nAs proposed by this RFC, all async functions return immediately, without\nevaluating their bodies at all. As discussed above, this is not convenient for\nuse cases in which you have an immediate \"initialization\" step - those use\ncases need to use a terminal async block, for example.\n\nAn alternative would be to have async functions immediately evaluate up until\ntheir first `await`, preserving their state until then. The implementation of\nthis would be quite complicated - they would need to have an additional yield\npoint within the `await`, prior to polling the future being awaited,\nconditional on whether or not the await is the first await in the body of the\nfuture.\n\nThis is also complicated from a user perspective - when a portion of the body\nis evaluated depends on whether or not it appears before all `await`\nstatements (which could possibly be macro generated). The use of a terminal\nasync block provide a clearer mechanism for distinguishing between the\nimmediately evaluated and asynchronously evaluated portions of a future with an\ninitialization step.\n\n## Using async/await instead of alternative asynchronicity systems\n\nA final - and extreme - alternative would be to abandon futures and async/await\nas the mechanism for async/await in Rust and to adopt a different paradigm.\nAmong those suggested are a generalized effects system, monads & do notation,\ngreenthreading, and stackfull coroutines.\n\nWhile it is hypothetically plausible that some generalization beyond\nasync/await could be supported by Rust, there has not enough research in this\narea to support it in the nearterm. Given our goals for 2018 - which emphasize\nshipping - async/await syntax (a concept available widely in many languages\nwhich interacts well with our existing async IO libraries) is the most logical\nthing to implement at this stage in Rust's evolution.\n\n# Prior art\n[prior-art]: #prior-art\n\nThere is a lot of precedence from other languages for async/await syntax as a\nway of handling asynchronous operation - notable examples include C#,\nJavaScript, and Python.\n\nThere are three paradigms for asynchronous programming which are dominant\ntoday:\n\n- Async and await notation.\n- An implicit concurrent runtime, often called \"greenthreading,\" such as\n communicating sequential processes (e.g. Go) or an actor model (e.g. Erlang).\n- Monadic transformations on lazily evaluated code, such as do notation (e.g.\n Haskell).\n\nAsync/await is the most compelling model for Rust because it interacts\nfavorably with ownership and borrowing (unlike systems based on monads) and it\nenables us to have an entirely library-based asynchronicity model (unlike\ngreenthreading).\n\nOne way in which our handling of async/await differs from most other statically\ntyped languages (such as C#) is that we have chosen to show the \"inner\" return\ntype, rather than the outer return type. As discussed in the alternatives\nsection, Rust's specific context (lifetime elision, the lack of a need for\nreturn type polymorphism here) make this deviation well-motivated.\n\n# Unresolved questions\n[unresolved]: #unresolved-questions\n\nThis section contains design extensions which have been postponed & not\nincluded in this initial RFC.\n\n## Final syntax for the `await` expression\n\nThough this RFC proposes that `await` be a built-in macro, we'd prefer that\nsome day it be a normal control flow construct. The unresolved question about\nthis is how to handle its precedence & whether or not to require delimiters of\nsome kind.\n\nIn particular, `await` has an interesting interaction with `?`. It is very\ncommon to have a future which will evaluate to a `Result`, which the user will\nthen want to apply `?` to. This implies that await should have a tighter\nprecedence than `?`, so that the pattern will work how users wish it to.\nHowever, because it introduces a space, it doesn't look like this is the\nprecedence you would get:\n\n```\nawait future?\n```\n\nThere are a couple of possible solutions:\n\n1. Require delimiters of some kind, maybe braces or parens or either, so that\n it will look more like how you expect - `await { future }?` - this is rather\n noisy.\n2. Define the precedence as the obvious, if inconvient precedence, requiring\n users to write `(await future)?` - this seems very surprising for users.\n3. Define the precedence as the inconvient precedence - this seems equally\n surprising as the other precedence.\n4. Introduce a special syntax to handle the multiple applications, such as\n `await? future` - this seems very unusual in its own way.\n\nThis is left as an unresolved question to find another solution or decide which\nof these is least bad.\n\n## `async for` and processing streams\n\nAnother extension left out of the RFC for now is the ability to process streams\nusing a for loop. One could imagine a construct like `async for`, which takes\nan `IntoStream` instead of an `IntoIterator`:\n\n```rust\nasync for value in stream {\n println!(\"{}\", value);\n}\n```\n\nThis is left out of the initial RFC to avoid having to stabilize a definition\nof `Stream` in the standard library (to keep the companion RFC to this one as\nsmall as possible).\n\n## Generators and Streams\n\nIn the future, we may also want to be able to define async functions that\nevaluate to streams, rather than evaluating to futures. We propose to handle\nthis use case by way of generators. Generators can evaluate to a kind of\niterator, while async generators can evaluate to a kind of stream.\n\nFor example (using syntax which could change);\n\n```rust\n// Returns an iterator of i32\nfn foo(mut x: i32) yield i32 {\n while x > 0 {\n yield x;\n x -= 2;\n }\n}\n\n// Returns a stream of i32\nasync fn foo(io: &AsyncRead) yield i32 {\n async for line in io.lines() {\n yield line.unwrap().parse().unwrap();\n }\n}\n```\n\n## Async functions which implement `Unpin`\n\nAs proposed in this RFC, all async functions do not implement `Unpin`, making\nit unsafe to move them out of a `Pin`. This allows them to contain references\nacross yield points.\n\nWe could also, with an annotation, typeck an async function to confirm that it\ndoes not contain any references across yield points, allowing it to implement\n`Unpin`. The annotation to enable this is left unspecified for the time being.\n\n## Async blocks as a first class syntax\n\nIn the future, we could support \"async blocks\" - a block which evaluates to a\nfuture rather than evaluating its content immediately:\n\n```rust\nlet future = async {\n println!(\"Hello from async block\");\n};\nprintln!(\"Hello from main\");\nblock_on(future);\n```\n\nThis is equivalent to the more verbose and confusing `async move || { }()`; for\nthe time being a macro in the futures crate called `async_block!` will expand\nto the immediately-called closure form, and we will leave the question of async\nblocks to the future.\n","editable",false,"branch","documentNavigation","repo","githubnext/chopin","repoId","7d1a8ac3-35b0-4dea-85d4-06a980f3bada","ownerId","org:89615882","site","nexthub","private","admin","settings","maintainer","triage","starred","stars",0,"watchers","watching","pinned","notify","views",[183,184,185,186,187,188,189,190,191,192,193,194,195],"navigation",{"_55":56,"_139":140,"_141":142,"_143":144,"_145":146,"_147":148,"_149":150},"sources",[],"viewer","meta",{"_131":132,"_133":134,"_135":136,"_43":32,"_137":14,"_138":32,"_49":50,"_51":50},"branches",[74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,14,127,128,129,130],"tags",[70,71,72,73],"cloneUrl","https://git.nexthub.sh/githubnext/chopin.git","color-controls-slice-1","color-controls-slice-2","color-controls-slice-3","color-controls-slice-4","Krzysztof-Cieslak-patch-1","Krzysztof-Cieslak-patch-2","Maggie/app-preview-toolkit","Maggie/ci-playwright-install-timeout","Maggie/collaborative-visual-decision","Maggie/design-audit","Maggie/generic-visual-decision-runtime","Maggie/impeccable-chopin-metadata","Maggie/jev-chat-product","Maggie/jev-composed-assessment","Maggie/native-document-layouts","Maggie/openui-composition-product","Maggie/openui-composition-trial","Maggie/planner-visual-authoring","Maggie/planner-visual-requests","Maggie/visual-selection-eval","artifacts/pr-419-live-preview-20261009","automation/pr-maintenance-state","automation/use-effect/callout-disabled-picker-8cf9e49ba5c09471","automation/use-effect/collaboration-options-ref-4e3a5a08a879a5ae","automation/use-effect/room-workspace-effective-access-a57d40866c71bed0","chore/bun-1.4.2","color-controls","color-controls-plan","comments","design-pr-assets","design/archived-decisions-badge","design/channel-route-remount","design/chat-decision-entry","design/conversation-analysis-markers","design/decision-evidence","design/settled-line-icon","dev/integration","diagram-step-controls","feat/liveapp-frontend-pilot","feat/local-experiments","feat/local-launcher-tracer","fix/autolink-mdx-crash","github-pills/2-pills","github-pills/3-hover-card","maggie/app-preview-toolkit","maggie/ci-playwright-install-timeout","maggie/collaborative-visual-decision","maggie/design-audit","maggie/generic-visual-decision-runtime","maggie/impeccable-chopin-metadata","maggie/jev-composed-assessment","maggie/native-document-layouts","maggie/openui-composition-product","maggie/openui-composition-trial","maggie/planner-visual-authoring","maggie/planner-visual-requests","maggie/visual-selection-eval","plain-text-fence-chrome","tokens/09-copy","wireframes/2-renderer","wireframes/3-planner","description","Let's compose rich plans together","owner","githubnext","section","","head","empty","pins",[165,166,167],"documents",{"_160":161,"_162":163},"code",{"_156":157,"_158":159},"automations",{"_153":154,"_155":-5},"delivery",{"_151":50,"_152":-5},"tag","04zvKQ8QOrDUF8TO1Ovz0Zy8_TT","releases","applications","workflows",3,"deployments","commits",1000,"changes",13,"counts",{"_164":163},"total",11,"issue",{"_168":158,"_170":181,"_15":158,"_172":182,"_53":174,"_175":32,"_176":174,"_177":159},{"_168":178,"_170":179,"_15":178,"_172":180,"_53":174,"_175":32,"_176":174,"_177":50},{"_168":169,"_170":171,"_15":169,"_172":173,"_53":174,"_175":32,"_176":174,"_177":163},"id","issues","name","Issues","filters",{},true,"saved","pinnable","count","tasks","Tasks",{},"Changes",{},{"_168":158,"_170":181,"_15":158,"_172":226,"_53":174,"_175":32,"_176":174},{"_168":178,"_170":179,"_15":178,"_172":225,"_53":174,"_175":32,"_176":174},{"_168":169,"_170":171,"_15":169,"_172":224,"_53":174,"_175":32,"_176":174},{"_168":221,"_170":222,"_15":221,"_172":223,"_53":32,"_175":32,"_176":174},{"_168":218,"_170":219,"_15":218,"_172":220,"_53":32,"_175":32,"_176":174},{"_168":153,"_170":216,"_15":145,"_172":217,"_53":32,"_175":32,"_176":174},{"_168":155,"_170":213,"_15":214,"_172":215,"_53":32,"_175":32,"_176":174},{"_168":151,"_170":211,"_15":151,"_172":212,"_53":32,"_175":32,"_176":174},{"_168":207,"_170":208,"_15":209,"_172":210,"_53":32,"_175":32,"_176":174},{"_168":141,"_170":205,"_15":141,"_172":206,"_53":32,"_175":32,"_176":32},{"_168":202,"_170":203,"_15":202,"_172":204,"_53":32,"_175":32,"_176":32},{"_168":199,"_170":200,"_15":199,"_172":201,"_53":32,"_175":32,"_176":32},{"_168":196,"_170":197,"_15":196,"_172":198,"_53":32,"_175":32,"_176":32},"decisions","Decisions",{},"changelog","Changelog",{},"roadmap","Roadmap",{},"Documents",{},"activity","Activity","insights",{},"Releases",{},"Deployments","automations/deployments",{},"Workflows",{},"discussions","Discussions",{},"goals","Goals",{},{},{},{},"groups","user","agents",[],"now",1794480520251,"sidebar","expanded"]