get_put_items is expecting <<"path">> := <<"/">> that cause function_clause error if not provided

[yingyingtang-brex]

Describe the bug
When using the Erlang server sdk, I got the error:
Got DOWN message from shotgun pid with reason: {function_clause, [{ldclient_update_stream_server, get_put_items,

The method get_put_items here is expecting a clause match of #{<<"path">> := <<"/">>, <<"data">> := #{<<"flags">> := Flags, <<"segments">> := Segments}}, however the data I passed in did not contain <<"path">> := <<"/">> thus failed.

I tried to update the method to be like:
get_put_items(#{<<"data">> := #{<<"flags">> := Flags, <<"segments">> := Segments}}) -> [Flags, Segments].
and it works.

I am wondering if it is a must to include "path" into the inout argument, or actually we can ignore it since we did not use "path" in this method anyway?

SDK version
launchdarkly_server_sdk

[zurab-darkly]

Hi @yingyingtang-brex thank you for reporting the issue. Could you please elaborate on

the data I passed in did not contain <<"path">> := <<"/">>

Did you observe this while the SDK was connected to the LaunchDarkly streaming service (i.e. https://stream.launchdarkly.com)? If yes, what steps did you take to cause that? If not, how did you pass the SDK the payload that didn't contain the path?

[yingyingtang-brex]

Hi,

Thanks for your reply.

I had this issue when trying to connect the SDK with the relay-proxy.
I first run the relay-proxy following the doc here. Then start the SDK application by passing the option for example like:
relay_proxy_url = 'http://localhost:8030'

    # options = %{
    #   base_uri: relay_proxy_url,
    #   stream_uri: relay_proxy_url,
    #   events_uri: relay_proxy_url
    # }

Then I will get the issue that data without <<"path">> := <<"/">> is passed into method get_put_items.
If I do not pass the above options and use the default url, I will have the data passed in containing <<"path">> := <<"/">>.

It might be some issues related to relay-proxy usage?

[zurab-darkly]

@yingyingtang-brex confirmed this is an oversight on our side. The workaround you suggest is reasonable. This should be fixed in the next release.

[bwoskow-ld]

@yingyingtang-brex apologies for leaving this issue open for so long, but this bug was resolved in version 1.0.0 of this SDK.