Closed zmckinnon closed 5 years ago
That's not an expected result, and we weren't aware of there being any problem with client-side stream updates via the relay. Off the top of my head, my first guess would be that the client-side SDK is simply failing to connect at all to the relay's streaming endpoint. Are you able to see in your browser console whether there is a successful request to <your relay URL>/eval/<environment ID>/...
?
Also, sorry if this is an obvious thing you already checked, but are you setting both baseUrl
and streamUrl
in your client configuration? They should both be set to the relay's base URL. If streamUrl
isn't set, it will try to use clientstream.launchdarkly.com
for live updates (which might or might not work depending on whether you have any network restrictions).
In the browser console, I do get a 200 when I send the request to https://launch-darkly-relay.dndbeyond.com/eval/5c98f0804421b90813e75ca5/eyJrZXkiOiJVbmtub3duIn0.
Here are screenshots:
We are setting baseUrl
and streamUrl
.
FeatureUtils.init({
clientId: config.launchDarklyClientId,
dispatch: store.dispatch,
user: {
key: 'Unknown',
},
options: {
baseUrl: 'https://launch-darkly-relay.dndbeyond.com',
streamUrl: 'https://launch-darkly-relay.dndbeyond.com',
eventsUrl: 'https://launch-darkly-relay.dndbeyond.com',
},
});
When I send the GET request to https://clientstream.launchdarkly.com/eval/5c98f0804421b90813e75ca5/eyJrZXkiOiJVbmtub3duIn0, I get:
event:put
data:{"encounter-builder-homebrew-monsters":{"version":265,"flagVersion":3,"value":false,"variation":1,"trackEvents":false},"encounter-builder-similar-encounters":{"version":265,"flagVersion":4,"value":false,"variation":1,"trackEvents":false},"encounter-builder-difficulty-bar":{"version":265,"flagVersion":29,"value":"new-c","variation":3,"trackEvents":false},"encounter-builder-grid-view":{"version":265,"flagVersion":7,"value":false,"variation":1,"trackEvents":false},"encounter-builder-suggested-monsters":{"version":265,"flagVersion":4,"value":false,"variation":1,"trackEvents":false},"encounter-builder-filter-monster-tags":{"version":265,"flagVersion":15,"value":true,"variation":0,"trackEvents":false},"encounter-builder-monster-grouping":{"version":265,"flagVersion":3,"value":false,"variation":1,"trackEvents":false},"encounter-builder-summary-tab":{"version":265,"flagVersion":26,"value":false,"variation":1,"trackEvents":false},"encounter-builder-filter-source-category":{"version":265,"flagVersion":9,"value":false,"variation":1,"trackEvents":false},"encounter-builder-randomizer-widget":{"version":265,"flagVersion":9,"value":true,"variation":0,"trackEvents":false}}
but when I send a GET request to https://launch-darkly-relay.dndbeyond.com/eval/5c98f0804421b90813e75ca5/eyJrZXkiOiJVbmtub3duIn0, I get:
event: ping
data:
Well, that last part, about the "ping", is an inconsistency with the regular service endpoint but an intentional one for now. The mechanism by which client-side flag values are normally delivered by that endpoint is not fully implemented in ld-relay, so it uses different semantics in which the service just tells the relay "there's been a change" (ping) and the relay responds by re-querying the flags. So it looks like ld-relay is doing what it's supposed to do in the current spec, and possibly the client-side JS SDK is not doing what it's supposed to do.
The other thing I would expect to see in the browser console is immediately that after the "ping" event appears in the eventsource response, another GET request should happen to the main flags endpoint (/sdx/evalx/...). I do see another request in your screenshot, although it doesn't show the full URL so I can't tell for sure if that's the one. If that happened, and it received a response containing the updated flag values, then... I guess that would be a client-side JS SDK bug too, but in a different location.
To clarify my last comment: Could you please provide the full request URLs of the requests to LaunchDarkly that are shown in your browser console—and the full response bodies of all of the GET requests made to /sdk/evalx/...
?
of course! I can provide that this evening.
The request that happens after https://launch-darkly-relay.dndbeyond.com/eval/5c98f0804421b90813e75ca5/eyJrZXkiOiJVbmtub3duIn0
is https://launch-darkly-relay.dndbeyond.com/sdk/evalx/5c98f0804421b90813e75ca5/users/eyJrZXkiOiJVbmtub3duIn0
.
The response for that is:
{"ContentManagement.EnableContentManagementLinkInCampaignDetails":{"value":true,"variation":0,"version":3,"trackEvents":false},"ContentManagement.EnablePreReleaseFeedbackForm":{"value":true,"variation":0,"version":7,"trackEvents":false},"app-portal.content-management-manifestlocation":{"value":"https://media.dndbeyond.com/content-management/asset-manifest.json","variation":1,"version":2,"trackEvents":false},"app-portal.encounter-builder-manifestlocation":{"value":"https://media.dndbeyond.com/encounter-builder/staging/asset-manifest.0.0.43.json","variation":1,"version":56,"trackEvents":false},"app-portal.megamenu-manifestlocation":{"value":"https://media.dndbeyond.com/mega-menu/asset-manifest.json","variation":1,"version":10,"trackEvents":false},"character-service-character-authorization":{"value":false,"variation":1,"version":6,"trackEvents":false},"character-tools":{"value":true,"variation":0,"version":6,"trackEvents":false},"critical-role-election-2019-survey-link":{"value":"https://www.surveymonkey.com/r/GPCQGFB","variation":2,"version":7,"trackEvents":false},"encounter-builder":{"value":false,"variation":1,"version":4,"trackEvents":false},"encounter-builder-difficulty-bar":{"value":"new-c","variation":3,"version":29,"trackEvents":false},"encounter-builder-filter-monster-tags":{"value":true,"variation":0,"version":15,"trackEvents":false},"encounter-builder-filter-source-category":{"value":false,"variation":1,"version":9,"trackEvents":false},"encounter-builder-grid-view":{"value":false,"variation":1,"version":7,"trackEvents":false},"encounter-builder-homebrew-monsters":{"value":false,"variation":1,"version":3,"trackEvents":false},"encounter-builder-monster-grouping":{"value":false,"variation":1,"version":3,"trackEvents":false},"encounter-builder-randomizer-widget":{"value":true,"variation":0,"version":9,"trackEvents":false},"encounter-builder-similar-encounters":{"value":false,"variation":1,"version":4,"trackEvents":false},"encounter-builder-suggested-monsters":{"value":false,"variation":1,"version":4,"trackEvents":false},"encounter-builder-summary-tab":{"value":false,"variation":1,"version":26,"trackEvents":false},"marketplace-redesign":{"value":true,"variation":0,"version":9,"trackEvents":false},"repository-character-endpoint":{"value":false,"variation":1,"version":2,"trackEvents":false},"unreleased-content-check":{"value":false,"variation":1,"version":2,"trackEvents":false},"vehicles-character":{"value":true,"variation":0,"version":25,"trackEvents":false},"vehicles-listing":{"value":true,"variation":0,"version":3,"trackEvents":false},"vehicles-listing.acquisitions-inc":{"value":true,"variation":0,"version":3,"trackEvents":false}}
As I am updating the flag in the Launch Darkly web console, requests are being made that return the correct value for the flag. (That feels like a good thing!) Unfortunately, the UI isn't being updated.
We are using:
"ldclient-js": "^2.9.5"
Well, at this point I'm pretty sure this is not an ld-relay bug. The relay endpoints are behaving as intended; the JS SDK is not. If you wouldn't mind pursuing this as a support issue, I think that would be best. The support team will probably bring me in on it anyway because I maintain the JS code too, but that would make more sense than hashing it out in Github issue comments in the ld-relay project.
One thing I would suggest trying in the meantime, just on general principle, is to update to a newer JS client. The current version is 2.12.4; that is with the newer NPM package name, which is now launchdarkly-js-client-sdk
. If you want to stick with the older ldclient-js
package for now, the last version of that is 2.10.2.
I'm not aware of any changes since 2.9.5 that would have affected this behavior, so as I said, this is just on general principle since it's something support will probably mention as well.
FYI: I updated to 2.10.2 and it is still not working đŸ˜¢ .
Opening a support ticket now.
I just took another look at this (after updating to 2.13.0) and I have some new information.
I have been testing by enabling and disabling the flag, and that doesn't seem to have any effect. But if I change the default value from true to false it DOES toggle the flag!
So, technically, this bug is either: a) When I toggle the flag on or off, it doesn't work or b) Works as intended!
That's very odd - I'm not sure what to make of it. Here's why:
I do see a new request after the flag is toggled, it's just that it returns a value of true for the flag. Even if targeting is off, it still returns true.
OHHHHHHHHHHHHH, holy crap, that is how it is supposed to work! Duh. I am so sorry about that. Thank you for all your help.
If targeting is off, serve true
Heh! No problem, glad it turned out to be something simple.
Guys Im facing a issue in my nest js backend. The API is able to get the correct values but the flag evaluation is not captured. Can you help me with this?
Guys Im facing a issue in my nest js backend. The API is able to get the correct values but the flag evaluation is not captured. Can you help me with this?
Hey I think I'm seeing the same thing. The flags are being evaluated in the api but not seeing it counted on LD. Did you get an answer?
When I use setup a client side flag via the default https://clientstream.launchdarkly.com, flags get updated in real time when I change the flag value.
When I proxy that through the ld-relay, I have to refresh the page to get the updated flag.
Is this an expected result? Is it possible to get the event stream working via the ld-relay?