[@vercel/flags-core] quiet noisy stream reconnect logs#395
Open
lucleray wants to merge 2 commits into
Open
Conversation
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Flag stream reconnects produce frequent, non-actionable logs in consumers like
logs-consumer-3. People seeing them have to decide whether to be concerned, but the SDK already retries (up to 15x with backoff) and falls back to embedded values in the meantime — so the per-attempt errors are noise. Context: help-flags thread.Stream errorfailures are now silent; the underlying error is only logged once retries are exhausted (attached to the existingMax retry count exceedederror).Stream initialization timeout, falling backand the polling equivalent now say they keep connecting/polling in the background, so the message reads as expected behavior rather than a failure.A recovery log ("N evaluations served from fallback") was discussed but deferred to a follow-up to keep this minimal.
Validation
black-box.test.tscases that previously assertedStream erroron retryable failures (502 / missing body / init-timeout) to assert it is not logged before exhaustion; reworded timeout assertions.pnpm test(black-box + stream-connection) andpnpm type-checkgreen.