Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WriteAPIImpl.WritePoint blocks on Encoding error #384

Open
CLIN42 opened this issue Aug 25, 2023 · 3 comments
Open

WriteAPIImpl.WritePoint blocks on Encoding error #384

CLIN42 opened this issue Aug 25, 2023 · 3 comments
Labels
bug Something isn't working

Comments

@CLIN42
Copy link

CLIN42 commented Aug 25, 2023

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

  1. Create a new writerAPI
  2. Create an empty write.Point
  3. call WritePoint on 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

@CLIN42 CLIN42 added the bug Something isn't working label Aug 25, 2023
@powersj
Copy link
Contributor

powersj commented Sep 12, 2023

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

@CLIN42
Copy link
Author

CLIN42 commented Sep 12, 2023

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.

@powersj
Copy link
Contributor

powersj commented Sep 12, 2023

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants