Skip to content

Fix decentralized learning fail#708

Merged
JulienVig merged 19 commits intodevelopfrom
694-decentralized-fail-julien
Jul 23, 2024
Merged

Fix decentralized learning fail#708
JulienVig merged 19 commits intodevelopfrom
694-decentralized-fail-julien

Conversation

@JulienVig
Copy link
Copy Markdown
Collaborator

@JulienVig JulienVig commented Jul 16, 2024

@JulienVig JulienVig marked this pull request as ready for review July 18, 2024 12:20
@JulienVig JulienVig requested a review from tharvik July 18, 2024 12:20
Copy link
Copy Markdown
Collaborator

@tharvik tharvik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great work on making decentralized work in browser! 🎉

a few logic/safety errors to fix and it can be merged 👍

this.aggregationResult,
timeout(undefined, "Timeout waiting on the aggregation result promise to resolve")
])
} catch (e) {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hum, so if this timeouts, we will still procede to the next communication round, but the payload will be invalid (already used by current round and very probably changed by it). I think breaking would be safer.

also, by creating the timeout in there, it is a timeout per communication round, not for the whole onRoundEnd, which is a bit unexcepted.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes I agree we should break/return here. However I don't see why a timeout per communication round is unexpected. Shouldn't we timeout whenever we may wait on a promise forever?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However I don't see why a timeout per communication round is unexpected. Shouldn't we timeout whenever we may wait on a promise forever?

yes, we should timeout for sure, but as each aggregator has a various number of communication round, the "onRoundEnd" timeout varies here which I find a bit weird. you can create the timeout promise at the beginning of the function and reference the same timeout in every communication round.
but yeah, maybe I'm overthinking this (won't be the first time), if you don't find it strange, let's keep it as it is (we don't really have a policy on timeouts anyway).

@JulienVig JulienVig requested a review from tharvik July 23, 2024 13:57
@JulienVig JulienVig merged commit edbfce9 into develop Jul 23, 2024
@JulienVig JulienVig deleted the 694-decentralized-fail-julien branch July 23, 2024 14:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

2 participants