You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Outages caused when system activities exceed the system’s capacity is a leading concern in system design. The ability to handle system activity efficiently, and gracefully limit the execution of activities before the system is under stress is a fundamental to system resiliency. .NET does not have a standardized means for expressing and managing resource limiting logic needed to produce a resilient system. This adds complexity to designing and developing resilient software in .NET by introducing an easy vector for competing resource limiting logic and anti-patterns. A standardized interface in .NET for limiting activities will make it easier for developers to build resilient systems for all scales of deployment and workload.
Users will interact with the proposed APIs in order to ensure rate and/or concurrency limits are enforced. This abstraction require explicit release semantics to accommodate non self-replenishing (i.e. concurrency) resource limits similar to how Semaphores o
We want to add the capability to control the format of the logs produced by our console logger. Currently, there is an option to choose between Default (logging on multiple lines with colors) and Systemd. We would like to add a compact format which will log using a single line, as well as a JSON based log format. We would also like to add an extension point so that users can specify their own custom log format. The motivation for these log formats can be found at https://github.com/dotnet/extensions/issues/2479. Finally, we need to be able to control the formatter used as well as the formatters via Configuration.
Scope
We are considering limiting the scope of the formatter API to Logging.Console for now, instead of Logging.Abstractions.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Planning | C | L | B | There are now more documentation of this process via OKRs and specs so I feel the transparency has increased. |
| Design | C | XL | B | Need to factor in infrastructure when designing features. E.g. Blazor WebJS. |
| Build/Infrastructure | D | XL | B | Need to align with rest of dotnet, we have too much "special" logic. |
| Coding | B | XXL | A | Need to respond to community PRs more promptly. |
| Testing | C | L | B | How do we know we have the right amount of coverage? Coverage is mostly driven by devs but may become out of date over time. Need improvements in tooling for debuggability/reliabil
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters