Todd Baert

@aepfli You also mentioned something about having another field in the `SyncFlags` RPC... I think it was to make some of the stream logic more isomorphic between the `EventStream` (RPC...

> of course i can elaborate. Currently within the RPC mode we do have the EventStream, which will send on the inital connection a message `provider_ready`, and for upcoming messages...

I'll check this out this weekend!

I think this is a good idea, and it "feels right" to me ergonomically. Make sure you add something to the [test-app](https://github.com/open-feature/js-sdk/blob/main/packages/nest/test/test-app.ts) to test and document this.

> I will have a look at what is wrong with the e2e test tomorrow @kaushalkapasi :) @lukas-reining @kaushalkapasi Seems to me like the test-harness git submodule was simply deleted....

@leakonvalinka you worked on some of this, might be a good one for you to document.

> Hey [@cupofcat](https://github.com/cupofcat), I agree that the first option sounds like the right approach. We should start by defining the expected behavior in the [provider lifecycle spec](https://flagd.dev/reference/specifications/providers/#flagd-provider-lifecycle). > > I...

> > I guess the question is, do we expect a lot of users today to actually rely on the behavior that different branches of the flag can evaluate to...

> So what I understand is that we have to create a hook that will be used to log the messages during flag life-cycle i.e before, after, error and finally...

> I think so too [@kevinmlong](https://github.com/kevinmlong). When using the logging hook, i think it is safe to assume that everything that was given to debug should also be seen. So...