Implement transient traits and identities

[khvn26]

Goal

To support additional use cases, such as evaluating identities in different contexts or managing anonymous identities, we aim to enable our SDK users to:

1. Evaluate flags against identities without persisting them.
2. Evaluate flags against identities while persisting only a subset of identity traits.

Solution Proposal

Make /api/v1/identities endpoints support optional boolean "transient" attributes both for the top-level identity object and a trait object.

Don't persist identities and traits marked as transient.

In SDKs, support transient: bool and transientTraits: list[str] optional keywords for the getIdentityFlags interface.

Related issues and discussions

Customer requests and use case discussions:

• #168, #77
• #1840, #1839

API tasks:

• https://github.com/Flagsmith/flagsmith/issues/4279
• https://github.com/Flagsmith/flagsmith/issues/4448
• https://github.com/Flagsmith/edge-api/issues/271
• https://github.com/Flagsmith/edge-api/issues/275

SDK tasks:

• https://github.com/Flagsmith/flagsmith-python-client/issues/88
• https://github.com/Flagsmith/flagsmith-js-client/issues/236
• https://github.com/Flagsmith/flagsmith-kotlin-android-client/issues/52
• https://github.com/Flagsmith/flagsmith-flutter-client/issues/62
• https://github.com/Flagsmith/flagsmith-php-client/issues/74
• https://github.com/Flagsmith/flagsmith-elixir-client/issues/35
• https://github.com/Flagsmith/flagsmith-ruby-client/issues/63
• https://github.com/Flagsmith/flagsmith-go-client/issues/132
• https://github.com/Flagsmith/flagsmith-rust-flag-engine/issues/14 + https://github.com/Flagsmith/flagsmith-rust-client/issues/22
• https://github.com/Flagsmith/flagsmith-java-client/issues/152
• https://github.com/Flagsmith/flagsmith-dotnet-client/issues/104
• https://github.com/Flagsmith/flagsmith-nodejs-client/issues/156
• https://github.com/Flagsmith/flagsmith-ios-client/issues/63

[novakzaballa]

@khvn26 I understand that we should implement transient traits because it is a quick and cost-effective way to cover some of the use cases related to contexts. While it could also help with anonymous identities or other use cases, we should keep the scope restricted to transient traits since that is the reason we decided to move ahead with its implementation. Also, as mentioned in this Notion regarding Anonymous identities https://www.notion.so/flagsmith/Anonymous-identities-904943c595474ae3b792f935109fb6f6 I think that for most we should persist annonymous identities or at least offer that option for most of the real use cases.

[novakzaballa]

Regarding the implementation, I would rather suggest to add a boolean attribute to the trait model, so you can specify and persist whether it is transient or not. That would allow customers to design the behavior of flags, and would allow transient flags without changes to the SDKs. We could also allow SDKs to request a trait to be marked as transient, but that would be optional.

[khvn26]

I would rather suggest to add a boolean attribute to the trait model, so you can specify and persist whether it is transient or no

@novakzaballa I agree with this. However, not all SDKs expose the trait model; some, mainly the server-side ones, accept a simple string to value mapping instead. I suggest we use the transientTraits: list[str] parameter for those and add a transient boolean property to the Trait model for SDKs that support them in their public interfaces.

[novakzaballa]

Agreed @khvn26

[khvn26]

As discussed here and offline, we're choosing to leave out the additional parameter in favour of extending the trait_value parameter type. In addition to current TraitValue | null type, the parameter should accept a mapping/object:

{
   transient: boolean
   value: TraitValue
}