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

Logs are not sent if the TCP server wasn't available when the logger was initialized #73

Closed
ggrossetie opened this issue Jul 8, 2022 · 5 comments

Comments

@ggrossetie
Copy link
Contributor

It seems that pino-socket can reconnect to a TCP server (using the reconnect option) but if the TCP server wasn't available when the logger (multistream?) was initialized then the server won't receive any data.

I've created a simple reproduction case because it's hard to explain but relatively straightforward to reproduce: https://github.com/Mogztter/pino-socket-reconnect

My observations:

  • pino-socket successfully reconnect (connect) to the TCP server and stops sending connect ECONNREFUSED 127.0.0.1:13370 as soon as the server is started
  • stream.write(data) in multistream is called
  • ThreadStream.write is called but writeSync is not, we keep calling nextFlush
  • the write function defined on the outputStream in TcpConnection is not called

Hopefully, I didn't miss something obvious 😅

@mcollina
Copy link
Member

mcollina commented Jul 9, 2022

Thanks for reporting! Would you like to send a Pull Request to address this issue? Remember to add unit tests.

@mcollina
Copy link
Member

mcollina commented Jul 9, 2022

This should be fixed in pino-socket, moving it there.

@mcollina mcollina transferred this issue from pinojs/pino Jul 9, 2022
@ggrossetie
Copy link
Contributor Author

This should be fixed in pino-socket, moving it there.

I cannot reproduce this issue when using TcpConnection directly.

Remember to add unit tests.

I can add a unit test to demonstrate that TcpConnection can reconnect even if the TCP server wasn't available at the start.

@ggrossetie
Copy link
Contributor Author

I think I found two issues!

The first one is that we shouldn't emit an error on the writable stream when reconnect is true (because it's a recoverable error). Otherwise, thread-stream will destroy the stream/worker.

The second one is that we do not emit outputStream.emit('open', socket.address()) when we reconnect. If the initial connect fails then we won't emit open and as a result we won't receive any data.

Here's the initial connect:

connect(() => {
outputStream.emit('open', socket.address())
})

And here's the reconnect where we do not emit open:

connect((err) => {
if (connected === false) {
return retry.backoff(err)
}
if (options.recovery) {
recoverEnqueuedData()
}
})

Is it OK to emit an open event every time we connect or reconnect?

@mcollina
Copy link
Member

Yes it should be ok to emit open multiple times

ggrossetie added a commit to ggrossetie/pino-socket that referenced this issue Jul 24, 2022
ggrossetie added a commit to ggrossetie/pino-socket that referenced this issue Jul 24, 2022
ggrossetie added a commit to ggrossetie/pino-socket that referenced this issue Jul 26, 2022
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

No branches or pull requests

2 participants