Handling both logged in and anon users causes log spam

[viraptor]

Describe the bug

When targeting some rule to a % of logged in users, I'm running into this line, spammed into logs:

Cannot evaluate targeting rules and % options for setting '...' (User Object is missing). You should pass a User Object to the evaluation methods like `get_value()` in order to make targeting work properly

But the expected way to handle this is either missing or not documented well. When the user is not provided, I get the mentioned message from https://github.com/configcat/ruby-sdk/blob/f51153b2f50a949454a1a79af5b57f4056f4b93a/lib/configcat/rolloutevaluator.rb#L226

But if I do provide it with a missing identifier (anonymous user), I'm going to run into https://github.com/configcat/ruby-sdk/blob/f51153b2f50a949454a1a79af5b57f4056f4b93a/lib/configcat/rolloutevaluator.rb#L247 (missing user_key)

There doesn't seem to be a way to explicitly say: This is an anonymous user who should be ignored for the purpose of this flag.

I could potentially work around that by using user: User.new('anonymous') and explicitly disabling that identifier for all flags, but that's easy to forget and suddenly enable some feature for majority of traffic.

The wording about the User object implies that it matches known users - and yes, I understand I could also fill the identifier with hash(ip) or something similar, but then I lose the ability to remove them with one match. On the other hand, I cannot make the query conditional in the app code, because the % rule is set on the configcat side and I'm not aware of it there.

To reproduce

Add a % rule Call get_value(:foo, false)

Expected behavior

Users not logged in get ignored for the purpose of a %-of-users check. (this is what the code already does, but it also spams the log on every check)

Alternatively a special User::Ignored is provided which always gets the default. (It would be User::Anonymous in my case, but the idea may not be generic enough)

SDK version

8.0.1

Language/Framework version

ruby 3.0

[kp-cat]

Hey @viraptor, Thanks for reporting this issue. We will discuss it with the dev team and get back to you.

[kp-cat]

Hey @viraptor,

Can you tell me more about your use-case? How dose the % rule look like? What kind of functionality dose the flag control?

I can see some options to handle this warning:

• We can implement a custom log filter option in Ruby like we already implemented in the java-sdk. With this method you can filter out these warnings.
• You can define a custom logger and filter out these warnings based on the [event_id]
• You can add an is_anonymous custom attribute to your User object and on the ConfigCat dashboard you can add an is_anonymous EQUALS true targeting rule to the top of the feature flag conditions. In this way, you can control from the dashboard what value the anonymous user will receive + you will not receive the warning.

Please let me know what do you think about these options

[viraptor]

Yes, the is_anonymous could work for us in theory. The reason I wanted to avoid it is the possibility to forget it. Our app has effectively 2 routes:

flowchart TD
    API --> frontend
    frontend --anon & cached--> browser
    API --logged in or anon--> browser

With the feature flags at the API level, the requests can come with the HTML rendering frontend service (anonymous), or the browser directly (small updates - logged in or anonymous). I really would really like to prevent the frontend path from being considered a user. The specific failure case I want to avoid is:

• dev creates a feature
• sets the feature to 5% of users
• forgets to add the is_anonymous check explicitly (there's no automatic reminder about it)
• frontend happens to be included in the 5%, the generated page ends up cached for a long time and served to effectively 99% of requests
• turning it off requires waiting for the cache to expire or an explicit flush

We're using the log filtering approach at the moment and monkeypatching the ConfigCat logger to drop event 3001. It's not ideal, but it works :)

[kp-cat]

Thanks @viraptor, for the insights. We'd like to keep these warning logs to help detect cases where the user object is missing or incomplete for a used targeting rule.

However, we also understand that there may be cases like the ones you mentioned where these logs might be unnecessary. Would it help you if we implemented a similar custom log filter in Ruby as we have in Java?

[github-actions[bot]]

This issue is marked stale because it has no activity in the last 3 weeks. The issue will be closed in one week. Please remove the stale flag to keep it open.

[github-actions[bot]]

This issue was closed due to no activity.