influxdb-client-go
                                
                                
                                
                                    influxdb-client-go copied to clipboard
                            
                            
                            
                        WriteAPIImpl.WritePoint blocks on Encoding error
Specifications
- Client Version: v2.12.3
 - InfluxDB Version: influxDB Cloud
 - Platform:AKS
 
Steps to reproduce
We're getting error influxdb2client E! point encoding error: no serializable fields while sending data to influx cloud. Strangely, after two exact errors,  influxdb2client seems to be blocked without any logging.
It was found that in method WriteAPIImpl.WritePoint  , Point will first be encoded, if that fails, error will be send to channel w.errCh <- err, which is never consumed. Because errCh is a buffered channel with lenth being 1, WritePoint blocks on the third encoding error
- Create a new writerAPI
 - Create an empty 
write.Point - call 
WritePointon the writeAPI with empty Point 
Expected behavior
empty point shouldn't block writing
Actual behavior
influxdb2client  blocks forever after two errors influxdb2client E! point encoding error: no serializable fields
Additional info
No response
Hi @CLIN42,
In the README there is an example of calling the errors function to capture write errors as they occur:
    // Get errors channel
    errorsCh := writeAPI.Errors()
    // Create go proc for reading and logging errors
    go func() {
        for err := range errorsCh {
            fmt.Printf("write error: %s\n", err.Error())
        }
    }()
Can you please share your code or add the above before you try to create points?
Thanks
Hi @powersj  Thanks for pointing out. I think I misundertood how the errors are being handled. Explicitly reading off the error channel should work as expected, like the example you refered. On the other hand, I think it can be emphasised  in the README  that Errors() must be called (it's mentioned in the code comment), then errors be processed, otherwise client may block indefinitely.
I think it can be emphasised in the README that Errors() must be called
sure do you want to put up a PR to add where it might be helpful to call out?