feat: Thread FDv1 fallback TTL through polling and streaming data sources - #1806
Conversation
|
@launchdarkly/js-sdk-common size report |
|
@launchdarkly/js-client-sdk-common size report |
|
@launchdarkly/js-client-sdk size report |
|
@launchdarkly/browser size report |
|
@cursor review |
e4fa9cb to
1400310
Compare
|
@cursor review |
46de8d4 to
6604149
Compare
|
@cursor review |
|
@cursor review |
29aefb7 to
73eeb30
Compare
|
@cursor review |
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit c01baaa. Configure here.
| terminalError, | ||
| } from './FDv2SourceResult'; | ||
|
|
||
| function getFallback(headers: { get(name: string): string | null }): boolean { |
There was a problem hiding this comment.
replacing with
e95c2f2 to
005c842
Compare
005c842 to
adfcb4d
Compare
|
Probably makes sense to wait for @kinyoklion's review since he left a comment. |
| // A 'none' payload (e.g. an HTTP 304, or a streaming 'none' intent) | ||
| // carries no state -- it confirms existing data is still current and | ||
| // must not clear a selector already obtained from a prior payload. | ||
| if (payload.type !== 'none') { |
There was a problem hiding this comment.
I think we really need to verify that an intent of none would never change the selector. Because if it did, then I assume we could get drift in the value used for the basis and then trigger a full transfer on a reconnect.
An aside is that a 304 in a browser is a replay, as it is in RN, but maybe it isn't for node client.
There was a problem hiding this comment.
In that the HTTP library in both cases re-presents the cached values.
…rces This commit will add in fallback TTL reading support as well as allow RN native event source read headers.
This will allow us to resolve directives that should override the fallback behavior such as goodbye or error
0f10c0e to
92a909d
Compare
BEGIN_COMMIT_OVERRIDE
chore: Thread FDv1 fallback TTL through polling and streaming data sources
END_COMMIT_OVERRIDE
This commit will add in fallback TTL reading support as well as allow RN native event source read headers.
NOTE: while working this PR, I found a lot of gaps in the RN eventsource. Internally tracked in ticket 2721 in sdk project.
Note
Overview
Extends FDv2 polling and streaming so FDv1 fallback directives carry optional TTL (
x-ld-fd-fallback/x-ld-fd-fallback-ttl, plus in-bandprotocolFallbackTTLon goodbye). Result builders now take a sharedFallbackDirectiveinstead of a bare boolean, and header TTL is interpreted in seconds and converted to milliseconds.Orchestration and data manager:
FDv2DataSourcechecksfdv1Fallbackon any initializer result (including transfer-none / HTTP 304-style payloads) and stops the initializer chain when the server directs FDv1.FDv2DataManagerBaseno longer overwrites the stored selector when anonepayload arrives withoutstate, so a prior full payload’s basis survives 304/none confirmations.Polling: Goodbye paired with a fallback directive is surfaced as
terminal_errorso the orchestrator moves off FDv1; recoverable errors with fallback skip initializer retries. Streaming: Open headers defer fallback until the next queued result; reconnect without fallback clears pending/committed fallback; ping-triggered polls merge deferred TTL without mutating the handler’s result object.CI package size limit for
@launchdarkly/js-client-sdk-commonis raised from 39300 to 44000 bytes.Reviewed by Cursor Bugbot for commit 18c0cfd. Bugbot is set up for automated code reviews on this repo. Configure here.