Skip to content

Conversation

@ningmingxiao
Copy link

@ningmingxiao ningmingxiao commented Dec 12, 2025

to fix containerd/containerd#12669 @fuweid @dmcgowan

func (c *serverConn) run(sctx context.Context) {
....
	go func(recvErr chan error) {
		defer close(recvErr)
		for {
			select {
			case <-c.shutdown:
				return
			case <-done:
				return
			default: // proceed
			}

			mh, p, err := ch.recv()
			if err != nil {
				status, ok := status.FromError(err)
				if !ok {
					recvErr <- err
					return
				}

				// in this case, we send an error for that particular message
				// when the status is defined.
				if !sendStatus(mh.StreamID, status) {
					return
				}

				continue
			}

recvErr will not receive an error when discard failed and go func will not return.

or we can catch discard error and return

func (c *serverConn) run(sctx context.Context) {
...
		case err := <-recvErr:
			// TODO(stevvooe): Not wildly clear what we should do in this
			// branch. Basically, it means that we are no longer receiving
			// requests due to a terminal error.
			recvErr = nil // connection is now "closing"
			if errors.Is(err, io.EOF) || errors.Is(err, io.ErrUnexpectedEOF) || errors.Is(err, syscall.ECONNRESET) {
				// The client went away and we should stop processing
				// requests, so that the client connection is closed
				return
			}
			log.G(ctx).WithError(err).Error("error receiving message")
                      //catch error here 
			_, ok := err.(syscall.Errno)
			if ok {
				return
			}

@kzys
Copy link
Member

kzys commented Jan 6, 2026

Sorry for the late reply. I've updated GitHub Actions. Can you rebase this PR against main?

@ningmingxiao
Copy link
Author

done thanks @kzys

@ningmingxiao
Copy link
Author

can you review this pr @kzys @dmcgowan

@dmcgowan
Copy link
Member

Did you confirm this fixed the issue? Looking through the bufio implementation of Discard, it is already doing something similar on the existing buffer. I don't see the allocation in that implementation either, it seems to just iterate filling up the existing buffer (defaulted to 4k).

@ningmingxiao ningmingxiao changed the title add batchDiscard fix: return a grpc error when discard failed Jan 13, 2026
@ningmingxiao
Copy link
Author

ningmingxiao commented Jan 13, 2026

you are right I create new pr will fix. @dmcgowan

@ningmingxiao ningmingxiao force-pushed the dev_patch branch 2 times, most recently from 2f33066 to 72984df Compare January 13, 2026 12:07
@dmcgowan
Copy link
Member

Catching any error on discard makes sense and exiting. If the discard did not succeed then the connection must be ended as it is no longer in a processable state.

@ningmingxiao
Copy link
Author

done thanks @dmcgowan

@ningmingxiao ningmingxiao changed the title fix: return a grpc error when discard failed fix: catch discard error and return Jan 15, 2026
Signed-off-by: ningmingxiao <ning.mingxiao@zte.com.cn>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Infinite loop in ttrpc on OOM

3 participants