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

API return values... net.service.handler.HandleMessage #98

Closed
btc opened this issue Sep 22, 2014 · 8 comments
Closed

API return values... net.service.handler.HandleMessage #98

btc opened this issue Sep 22, 2014 · 8 comments

Comments

@btc
Copy link
Contributor

btc commented Sep 22, 2014

Continuing discussion from #69 (comment)

@perfmode good point, that doesn't make much sense. See https://github.com/jbenet/go-ipfs/blob/net/net/service/service.go#L183-L188 Think it should just return a message, and handle/log/whatever its own error?

Yeah.

If something goes wrong when handling a message, trttd might be to propagate the error upward. ie. an error channel or an error recorder (à la vitess) used by the service (DHT, BitSwap)

@jbenet
Copy link
Member

jbenet commented Sep 22, 2014

oh nice find!!

if only ... you know ... we could just import those types........! grrr. soon.

@btc
Copy link
Contributor Author

btc commented Sep 22, 2014

some initial work in #101

TODO decide on an error logging strategy and start passing errors up to the IPFS Core.

@whyrusleeping
Copy link
Member

So, what about the core having a master context with an error channel for all child contexts to report errors through. This way when the core 'Starts' it can start reading on the channel, and that way will never cause any deadlocks or loss of data in its children who are sending errors up through the channel

@btc
Copy link
Contributor Author

btc commented Sep 22, 2014

+1

On Mon, Sep 22, 2014 at 4:41 PM, Jeromy Johnson notifications@github.com
wrote:

So, what about the core having a master context with an error channel for all child contexts to report errors through. This way when the core 'Starts' it can start reading on the channel, and that way will never cause any deadlocks or loss of data in its children who are sending errors up through the channel

Reply to this email directly or view it on GitHub:
#98 (comment)

@jbenet
Copy link
Member

jbenet commented Sep 22, 2014

+1 —
Sent from Mailbox

On Mon, Sep 22, 2014 at 1:55 PM, Brian Tiger Chow
notifications@github.com wrote:

+1
On Mon, Sep 22, 2014 at 4:41 PM, Jeromy Johnson notifications@github.com
wrote:

So, what about the core having a master context with an error channel for all child contexts to report errors through. This way when the core 'Starts' it can start reading on the channel, and that way will never cause any deadlocks or loss of data in its children who are sending errors up through the channel

Reply to this email directly or view it on GitHub:

#98 (comment)

Reply to this email directly or view it on GitHub:
#98 (comment)

@btc
Copy link
Contributor Author

btc commented Sep 22, 2014

Here's a radically unintrusive approach:

https://gist.github.com/perfmode/f2951c1ed3a02c484d0b#file-context_test-go

@jbenet
Copy link
Member

jbenet commented Sep 22, 2014

<3 https://gist.github.com/perfmode/f2951c1ed3a02c484d0b#comment-1304444

On Mon, Sep 22, 2014 at 2:56 PM, Brian Tiger Chow notifications@github.com
wrote:

Here's a radically unintrusive approach:

https://gist.github.com/perfmode/f2951c1ed3a02c484d0b#file-context_test-go


Reply to this email directly or view it on GitHub
#98 (comment).

@whyrusleeping
Copy link
Member

closing, no longer relevant

@aschmahmann aschmahmann mentioned this issue Feb 18, 2021
73 tasks
ribasushi pushed a commit that referenced this issue Jul 4, 2021
enable configuring several log outputs
ariescodescream pushed a commit to ariescodescream/go-ipfs that referenced this issue Oct 23, 2021
@aschmahmann aschmahmann mentioned this issue Dec 1, 2021
80 tasks
laurentsenta pushed a commit to laurentsenta/kubo that referenced this issue Feb 25, 2022
laurentsenta pushed a commit to laurentsenta/kubo that referenced this issue Feb 25, 2022
laurentsenta pushed a commit to laurentsenta/kubo that referenced this issue Mar 4, 2022
laurentsenta pushed a commit to laurentsenta/kubo that referenced this issue Mar 4, 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

3 participants