Skip to content
A repository for gRFCs
Branch: master
Clone or download
yashykt Add note about receiving NO SERVICE CONFIG (#147)
* Add note about receiving NO SERVICE CONFIG

* Reviewer comments
Latest commit d4fc009 Jun 7, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
A14_graphics Fix typo in A14-channelz (#146) Jun 4, 2019
A6_graphics Add more diagrams to retry design Aug 25, 2017
L38_graphics L38 initial proposal Sep 24, 2018
L50_graphics L50: gRPC Objective-C Interceptor (#140) Jun 3, 2019
L9_graphics L9: new balancer and resolver APIs for gRPC-go (#30) Feb 6, 2018
.gitignore Git ignore DS_Store Mar 9, 2017
A1-http-connect-proxy-support.md Reference Java APIs for implemented proposals Apr 4, 2018
A10-avoid-grpclb-and-service-config-for-localhost-and-ip-literals.md minor wording fix Nov 1, 2018
A14-channelz.md Fix typo in A14-channelz (#146) Jun 4, 2019
A15-promote-reflection.md A15: Promote Reflection Proto out of Alpha Jun 13, 2018
A16-binary-logging.md
A17-client-side-health-checking.md Specify validation rule Mar 2, 2019
A18-tcp-user-timeout.md update implementation status for Go Nov 13, 2018
A2-service-configs-in-dns.md Update after A21 service config error handling changes (#133) Mar 8, 2019
A21-service-config-error-handling.md Add note about receiving NO SERVICE CONFIG (#147) Jun 7, 2019
A24-lb-policy-config.md A24: Update GrpcLbConfig to add child policy in LoadBalancingConfig (#… Mar 25, 2019
A3-channel-tracing.md
A5-grpclb-in-dns.md Document gRPCLB dual protocol (http+https) workaround Jun 20, 2018
A6-client-retries.md Remove repetitive description Mar 4, 2019
A8-client-side-keepalive.md keepalive: Document C's option names Jul 12, 2018
A9-server-side-conn-mgt.md keepalive: Document C's option names Jul 12, 2018
G1-true-binary-metadata.md Review feedback Apr 4, 2017
GRFC-TEMPLATE.md Initial commit of seed information into the gRPC proposal repo. Jan 13, 2017
L1-cpp-stream-coalescing.md Rename language proposal files for consistency (#113) Oct 24, 2018
L11-ruby-interceptors.md Rename language proposal files for consistency (#113) Oct 24, 2018
L12-csharp-interceptors.md Update status to Approved Jun 7, 2018
L13-python-interceptors.md Update status to Approved Feb 1, 2019
L15-php-interceptors.md Rename language proposal files for consistency (#113) Oct 24, 2018
L17-cpp-sync-server-exceptions.md Rename language proposal files for consistency (#113) Oct 24, 2018
L18-core-remove-grpc-alarm.md Rename language proposal files for consistency (#113) Oct 24, 2018
L2-cpp-completion-queue-creation-api.md Rename language proposal files for consistency (#113) Oct 24, 2018
L21-core-gpr-review.md Rename language proposal files for consistency (#113) Oct 24, 2018
L22-cpp-change-grpcpp-dir-name.md Rename language proposal files for consistency (#113) Oct 24, 2018
L23-node-protobufjs-library.md make load, loadSync accept multiple files at once (#143) May 16, 2019
L24-cpp-extensible-api.md Rename language proposal files for consistency (#113) Oct 24, 2018
L25-cpp-expose-buffer-reader-writer.md Rename language proposal files for consistency (#113) Oct 24, 2018
L26-cpp-raw-codegen-api.md Update and rename gRFC Jul 2, 2018
L29-cpp-opencensus-filter.md Rename language proposal files for consistency (#113) Oct 24, 2018
L30-cpp-control-max-threads-in-SyncServer.md Rename language proposal files for consistency (#113) Oct 24, 2018
L31-php-intercetor-api-change.md L31: PHP interceptor API change with deserialize argument Oct 24, 2018
L32-node-channel-API.md Expand createCall documentation in L32 Jun 27, 2018
L33-node-checkServerIdentity-callback.md Updated approver and discussion link thread. Jul 23, 2018
L34-cpp-opencensus-span-api.md Rename language proposal files for consistency (#113) Oct 24, 2018
L35-node-getAuthContext.md Move L35 to be with other proposals (#99) Sep 20, 2018
L38-objc-api-upgrade.md Mark status as Final Jan 4, 2019
L39-core-remove-grpc-use-signal.md Rename language proposal files for consistency (#113) Oct 24, 2018
L40-node-call-invocation-transformer.md L40: resolve comments on PR Sep 27, 2018
L41-node-server-async-bind.md L41: Add error to callback Sep 28, 2018
L42-python-metadata-flags.md Update the compare phrase between ChannelReadyFuture and wait-for-ready Nov 8, 2018
L43-node-type-info.md L43: Add discussion thread link Nov 19, 2018
L44-python-rich-status.md Fix typo Feb 22, 2019
L45-cpp-server-load-reporting.md Rename L38-cpp.. Jan 25, 2019
L46-python-compression-api.md L46: Python Compression API (#125) Apr 9, 2019
L48-node-metadata-options.md L48: Node Metadata options (#127) Mar 15, 2019
L49-objc-flow-control.md Update status of flow control to "approved" May 20, 2019
L5-node-client-interceptors.md Rename language proposal files for consistency (#113) Oct 24, 2018
L50-objc-interceptor.md L50: gRPC Objective-C Interceptor (#140) Jun 3, 2019
L51-java-rm-nano-proto.md L51: Java Remove Nano Protobuf May 22, 2019
L6-core-allow-cpp.md Rename language proposal files for consistency (#113) Oct 24, 2018
L7-go-metadata-api.md L7: Go Metadata API proposal (#25) Jan 17, 2018
L8-cpp-internalization.md Rename language proposal files for consistency (#113) Oct 24, 2018
L9-go-resolver-balancer-API.md L9: new balancer and resolver APIs for gRPC-go (#30) Feb 6, 2018
LICENSE Change license to Apache 2.0 Aug 30, 2017
P1-cloud-native.md Add convention for naming files Mar 13, 2017
P3-grfcs-for-core-api-changes.md P3: Core API changes (including additions) need a gRFC (#52) Feb 2, 2018
P4-grpc-cve-process.md P4: Proposal for gRPC's CVE process. (#138) Apr 26, 2019
README.md Rename language proposal files for consistency (#113) Oct 24, 2018

README.md

gRPC RFCs

Introduction

This repo contains the design proposals for substantial feature changes for gRPC that need to be designed upfront. The goal of the upfront design process is to:

  • Provide increased visibility to the community on upcoming changes and the design considerations around them.
  • Provide ability to reason about larger “sets” of changes that are too big to be covered either in an Issue or in a PR.
  • Establish a consistent process for structured participation by the community on large changes, especially those that impact multiple runtimes and implementations.

Prerequisites

This process needs to be followed for any significant change to gRPC that needs design. Changes that are considered significant can be:

  • Features that need implementation across runtimes and languages.
  • Process changes that affect how the gRPC product is implemented.
  • Breaking changes to the public API (i.e. semver major changes).

Process

  1. Fork the repo and copy the template GRFC-TEMPLATE.md.
  2. Rename it to $CategoryName-$Summary, eg.: A6-client-retries.md (see category definitions below)
    • For language-specific proposals, include the name of the language: L##-$Language-$Summary. Canonical names: core, cpp, csharp, go, java, node, objc, php, python, ruby.
  3. Write up the RFC.
  4. Submit a Pull Request.
  5. Someone from gRPC team will be assigned as an APPROVER as part of this review. Once the APPROVER is assigned, the OWNER needs to start a discussion on grpc-io and update the PR with the discussion link. After this is done, the OWNER should update the gRFC to the state of In Review. It is expected that the APPROVER will help the OWNER along this process as needed.
  6. For at least a period of 10 business days (the minimum comment period), it is expected that the OWNER will respond to the comments and make updates to the RFC as new commits to the PR. Through the process, the discussion needs to be kept to the designated thread in the mailing list in order to avoid splintering conversations. The OWNER is encouraged to solicit as much feedback on the proposal as possible during this period. PR comments should belimited to formatting and vocabulary.
  7. If there is consensus as deemed by the APPROVER during the comment period, the APPROVER will mark the proposal as final and assign it a gRFC number. Once this is assigned (as part of the closure of discussion), the OWNER will update the state of the PR as final and submit the PR. Commits must not be squashed; the commit history serves as a log of changes made to the proposal.

APPROVER

  • By default a11r is the approver unless another approver is assigned on a per-proposal basis.
  • If the assigned APPROVER and the OWNER cannot satisfactorily settle an issue, the final APPROVER is still a11r.

Proposal Categories

The proposals shall be numbered in increasing order.

  • #An - Affects all languages.
  • #Pnn - Affects processes, such as the proposal process itself.
  • #Lnnn - Language specific changes to external APIs or platform support.
  • #Gnnnn - Protocol level changes.

Proposal Status

  1. Every uncommitted proposal candidate starts off in the Draft state.
  2. After it accepted for review and posted to the group, it enters the In Review state.
  3. Once it is approved for submission by the arbiter, it goes into the Final state. Only minor changes are allowed (what qualifies as minor is left to the APPROVER).
  4. If a proposal needs to be revisited, it can be moved back to the Draft or In Review state. This can happen if issues are discovered during implementation. At which point, the review process as described above must be followed.
  5. Once a proposal is Final and if it has been implemented by a language, it can be updated to a status of Implemented with the list of languages listed (listing versions is not required).
You can’t perform that action at this time.