thetanz / openfeature-al Goto Github PK

The Error message when I try to install my extension

{"error":{"code":"Unknown","message":"The specified file is not an extension file. (Parameter 'stream') CorrelationId: 6851a81b-c3c3-4986-9978-d8a953dbda9b."}}
I was able to reproduce this with postman.

When ever I unstall the open feature app in "clean" mode, so with removing all data that belongs to it. It will get pulled and installed from appsource automatically and my publish will work again.
Otherwise I get the error stated above.

Oddly, this only happens if deployed though my pipeline. Through the UI and DEV endpoint it works without problems.
And even if I remove the dependency, the error persists. Only the complete removal of the Open Feature extension will solve this.

Let me know if there is any think I can give, that could help you.

OpenFeature for AL needs to have a transparent and community-accepted CI\CD automation which will enable PR validation and continues AppSource deployment.

Describe the solution you'd like
Plug an AL-Go to the OpenFeature PTE and AppSource branches

I have created a feature flag called "MyFeat" and enabled it. Works fine!

When I delete the feature flag, the functionality is still active. Shouldn't it be disabled? Or what is the intended behaviour?

Most of the users of OpenFeature-al app will be other ISV providers who will be using it as a dependency for their commercial products. We need to document such use conditions within a README.md.

Describe the bug
We have cases where SetContext procedure reports Operation exceeded time threshold telemetry with executionTime of more than 30 seconds.

Expected behaviour
SetContext should be within 00:00:10 seconds maximum.

Additional context
Currently, for PostHug provider within the SetContext procedure, we are calling PostHug API per each user context. It's possible to call PostHug API once to report all users within one call or to report just one user just to define user properties.

Describe the solution you'd like
HI @vody, I really like the idea and solution you came up with here.
When implementing this feature management for PTEs, I could image that a more manual approach to the decision making would be usefull. Similar to what MS has.

My question would be if you already thought about this.
I imagine a subpage where the ADMIN could select the users for which a given feature would be enabled.
Given that the DEV flags a feature as per User instead of per company or even per environment
If tested the feature could then be enabled for the whole environment.

And this is not really a feature request, I just want to get your opinion and input, and then I want to contribute this feature.

Describe the bug
When a feature is disabled, and the application are is used on a field, the field does not get hidden. Just the value is not displayed anymore

To Reproduce
Steps to reproduce the behavior:

1. create a field with a feature application area
2. enable the feature and verify the field is shown
3. reload the page with ctrl+F5
4. see the field is still there

Expected behavior
The field gets hidden completely

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
This is again maybe more a question of what I am doing wrong, or to understand how the application areas work exactly. I know you are already using this app in production so I guess you might have some more insight.
I did test this with the posthog provider. Everything else seems to be working quite well.

Describe the bug
CONDITIONS provider failed to execute GetEnabled method: Sorry, the current permissions prevented the action. (TableData Condition_FF_TSL Condition Read: OpenFeature)

Expected behavior
No issue

Describe the bug
Provider_FF_TSL.ConnectionInfo procedure reporting Operation exceeded time threshold (SQL query) with executionTime more than 5 seconds.

Expected behaviour
Provider_FF_TSL.ConnectionInfo should be within longRunningThreshold 00:00:00.75

Additional context
We reading ConnectionInfo from isolated storage. To speed it up, we should be caching this information to do not to read it multiple times.

Describe the bug
OpenFeature extension brakes a copy environment process:

To Reproduce
Steps to reproduce the behaviour:

1. Install OpenFeature as it to any SaaS environment without any app which is using it.
2. Try to create a copy of this environment
3. See error

Expected behaviour
No error should appear.

Optimizely require having hosted agent to handle decision-making. It's possible to implement a provider to work with Agent API and provide ISV's with instructions on how to host their agents.

Harness provides proxy service endpoints (https://config.ff.harness.io/api/1.0 and https://events.ff.harness.io/api/1.0) designed to be used by client SDK's. These endpins are way faster and provide the ability to report back feature usage information back to Harness.

Authentication

POST https://config.ff.harness.io/api/1.0/client/auth
Content-Type: application/json

{
    "apiKey": "{{APIKey}}",
    "target": {
        "identifier": "{{Target}}",
        "name": "Anonymous User",
        "anonymous": true,
        "attributes": {}
    }
}

Fetch Flags

GET https://config.ff.harness.io/api/1.0/client/env/{{Environment}}/target/{{Target}}/evaluations?cluster={{ClusterIdentifier}}
Authorization: Bearer {{Authentication.response.body.authToken}}

Post Metrics

POST https://events.ff.harness.io/api/1.0/metrics/{{Environment}}?cluster={{ClusterIdentifier}}
Content-Type: application/json
Authorization: Bearer {{Authenticate.response.body.authToken}}

{
    "metricsData": [
        {
            "timestamp": 1683682952998,
            "count":1,
            "metricsType":"FFMETRICS",
            "attributes": [
                { "key":"featureIdentifier", "value":"{{Flag}}" },
                { "key":"variationIdentifier", "value":"{{Identifier}}" },
                { "key":"target", "value":"{{Target}}" }
            ]
        }
    ]
}

To progress on this we need to be able to parse JWT token in BC. There are already dotnet available but need a proper AL wrapper.
Client Add-in will not be an acceptable option as it makes the overall solution too complex to enable Harness publisher. Option with external parser is not acceptable as well as non of the partners want's their access key to be exposed to third party service.

Is your feature request related to a problem? Please describe.
As an ISV using PostHug Provider, we see high usage of a PostHug API from OpenFeature. This becomes quite costly, and ideally, we would like to have a cheaper solution for it. For example, currently, we are sending 52M requests to PostHug /decide API. Most of these requests are due to a background session (API calls to BC) where no flag logic is actually needed.

Describe the solution you'd like
For a background session, it would be better to validate flags only if it is required.

Describe alternatives you've considered
The alternative is to have a new self-hosted provider, which is a chapter to host, then a third-party service.

Is your feature request related to a problem? Please describe.
Have you thought about providing this app as (RunTime) Version released for OnPrem?

Describe the solution you'd like
I really enjoyed your presentation and we would really like to use this app, but It would be very helpful if you could use this app for OnPrem.

We would like to use your extension in our own apps for OnPrem Customers and for PTE Customizations, therefore it would be useful to get app files from a nuget or another artifact.

e.g. do you plan to enable DownLoad of RunTime Version as soons as this is supported by microsoft?

Is your feature request related to a problem? Please describe.
As an ISV provider, we want to enable early access scenarios for feature flags. This requires allowing users to select features which why would like to enable.

Describe the solution you'd like
PostHug now has a Early Access Feature Management, which enables such a scenario from backed. We would like this to be included in a current app. So then the user would be able to enable such a feature for himself or for his organization from a Features page.

As part of the #11 fix, we stop reporting identities to PostHog. This was an urgent fix which was required as we had cases where OpenFeature was about to be installed on the environment with 250 companies and 450 users, which with old implementation, led to thousands of calls to the PostHog API.

We do want to be able to maintain identities on the PostHog side but at an acceptable cost.

Describe the solution you'd like

• Utilise a PostHog Batch Events API to report identities in bulk on install
• Report identities once per database instead of per company
• Make identity reporting optional and set the default behaviour not to report identities. This should include documenting a difference.