Accidential non-nil error when batching with WriteAPIBlocking

[danielorbach]

Specifications

• Client Version: v2.10.0
• InfluxDB Version: v2.4
• Platform: Docker container

Steps to reproduce

Influx PR draft

1. Create a new blocking write-API

   c := influxdb2.NewClient(*influxServerURL, *influxAuthToken)
   defer c.Close()
   writeAPI := c.WriteAPIBlocking(*influxOrg, *influxBucket)

2. Enable batching

   writeAPI.EnableBatching()

3. Write/Flush

   err := writeAPI.WritePoint(context.Background(), write.NewPointWithMeasurement("m"))
   if err != nil {
       return fmt.Errof("write: %w", err)
   }
   return nil

   err := writeAPI.Flush(context.Background())
   if err != nil {
       return fmt.Errof("flush: %w", err)
   }
   return nil

Expected behavior

We expect calls to Write/Flush to return a non-nil error on successful writes to the database.

Actual behavior

The returned error from Write/Flush is write: <nil> / flush: <nil> instead of a nil error.

Additional info

Looking at the code and commit history, I've found w.service.WriteBatch returns a concrete error type (i.e., *http2.Error).
However, returning a nil pointer (of type *http2.Error) as an interface is not a nil interface (i.e., nil) but a non-nil interface with a valid underlying type and a nil value.
So the test err != nil is always true.

I suggest a quick fix in Pull Request #359 , yet there may be merit in a more comprehensive refactoring to always return type error interface errors instead of the concrete *http2.Error.

Possibly related Pull Requests:

• feat: add implicit batching to writeAPIBlocking #350

A workaround for those who come across this issue in the meanwhile:

import	http2 "github.com/influxdata/influxdb-client-go/v2/api/http"

// https://github.com/influxdata/influxdb-client-go/pull/359
func workaround(err error) error {
	if e, ok := err.(*http2.Error); ok {
		if e == nil {
			return nil
		}
	}
	return err
}

err := workaround(writer.Flush(ctx))
if err != nil {
	return fmt.Errorf("flush: %w", err)
}

[powersj]

next steps: finish up and land #359