go.mod: bump pool to v0.7.1-beta#1314
Conversation
In this commit, we bump the embedded pool dependency to v0.7.1-beta, which pulls in the partial re-subscribe fix from lightninglabs/pool#521. Before, a single per-account failure in HandleServerShutdown would bail the whole re-subscribe loop and silently leave the remaining accounts un-subscribed (and filtered as offline at matching time) until the trader process restarted. The loop is now best-effort: per-account errors are logged with the trader key, every account still gets a re-subscribe attempt, and the aggregated error is returned to the caller via errors.Join so we don't lose the signal.
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request updates the Highlights
New Features🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
| dying on EOF, jittered reconnect backoff, and a fix for stream | ||
| handling in the pending-open-channel consumer. | ||
|
|
||
| * Updated [`pool` to |
There was a problem hiding this comment.
Nit: We usually remove the old upgrade entry in the release-notes for the sub-servers, if there's a newer one available. I.e. this should replace the above pool entry, and not be added separately.
I can edit this in my upcoming release PRs though, so ok to leave it as is if you want to.
In this PR, we bump the embedded
pooldependency up tov0.7.1-beta. The motivation is a single auctioneer reliability fix that follows the same severity class as the EOF reconnect work we pulled in forv0.7.0-beta.The fix is for
HandleServerShutdown(lightninglabs/pool#521). Before, when the trader's subscription stream went down and the client tried to re-subscribe every account against the new stream, the loop bailed on the first per-account failure. Because the accounts were drained out of the in-memorysubscribedAcctsmap before the loop ran, any account after the failing one in iteration order was silently lost. The trader looked healthy locally, but the auctioneer saw it as offline and filtered its orders at matching time until the process restarted. The symptom was also intermittent in practice, since Go's randomized map iteration meant the set of "survivors" changed between runs.The new behavior is best-effort: per-account errors are logged with the trader key for operator visibility, every account still gets a re-subscribe attempt against the new stream, and the aggregated error is returned to the caller via
errors.Joinso the rpcserver still sees a non-nil signal when anything went wrong.The diff itself is minimal: just
go.mod/go.sumand a one-bullet entry under### Poolin the upcoming0.17.0release notes.Test plan
go build .on the main lit module is unaffected by the bump (pre-existingperms/mock.golnd-API breakage is in a separate sub-module).