Fix default value updates for feature toggles

[Copilot]

Toggle default values were immutable after first access. When code updated feature flag defaults (e.g., defaultValue=false → defaultValue=true after rollout), the system returned stale stored values, ignoring new defaults.

Root Cause

Database constraint (configurationId, value, scope) allowed multiple values per toggle/scope. Provider silently ignored insert failures instead of updating defaults.

Changes

Database Schema

• Changed unique constraint to (configurationId, scope) - one value per toggle/scope
• Added MIGRATION_7_8 with correlated subquery to preserve data integrity during migration

Provider Logic

// Before: silently ignored
catch (e: SQLiteConstraintException) { }

// After: update existing default
catch (e: SQLiteConstraintException) {
    configurationValueDao.updateConfigurationValueSync(
        togglesConfiguration.id,
        defaultScope.id,
        toggle.value!!
    )
}

Behavior

• Default scope: Auto-updates when code provides new defaults
• User scopes: Preserved, never auto-update
• Query priority: User scope → Default scope → Code parameter

Testing

• Updated existing tests to expect new behavior
• Added test covering the issue scenario
• Added migration test for duplicate value handling

Impact

No breaking changes. Database migrates automatically on upgrade. Default values now update with code changes while preserving user-set values in non-default scopes.

---

Documentation: See docs/DEFAULT_VALUE_UPDATE_FIX.md for technical details.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• dl.google.com
  • Triggering command: /usr/lib/jvm/java-21-openjdk-amd64/bin/java /usr/lib/jvm/java-21-openjdk-amd64/bin/java --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-opens=java.base/java.nio.charset=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED --add-opens=java.xml/javax.xml.namespace=ALL-UNNAMED --add-opens=java.base/java.time=ALL-UNNAMED -Xms500m -Xmx12120m -Dfile.encoding=UTF-8 -Duser.country -Duser.language=en (dns block)
• esm.ubuntu.com
  • Triggering command: /usr/lib/apt/methods/https /usr/lib/apt/methods/https (dns block)
• scans-in.gradle.com
  • Triggering command: /usr/lib/jvm/java-21-openjdk-amd64/bin/java /usr/lib/jvm/java-21-openjdk-amd64/bin/java --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-opens=java.base/java.nio.charset=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED --add-opens=java.xml/javax.xml.namespace=ALL-UNNAMED --add-opens=java.base/java.time=ALL-UNNAMED -Xms500m -Xmx12120m -Dfile.encoding=UTF-8 -Duser.country -Duser.language=en (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Difficult to differentiate between old default, updated default and user set value</issue_title>
<issue_description>Hi! We have a bit of a conundrum.

When requesting a Toggle the first time, it will store itself with a default value. Any subsequent request to that toggle will then reply with the same stored value, regardless of any new default passed. As there is no way to determine if the value actually comes from an old default or from a user actively toggling the toggle, it becomes difficult to update the default.

Here is a a scenario

1. A query for the Boolean Toggle for key "thought-experiment-A-roll-out" is added in a client application with default set to the value of the feature flag, which is false as the feature has not yet been rolled out.
2. The feature is rolled-out to the test environment, and trying to respect the user's wishes, we check the toggle, using the updated value of the feature flag as the default parameter to Toggles.
3. Toggles fetches the old default value, and since we have a return value, the new default is simply discarded. Now we cannot determine if the returned value is an old default or something the local developer has set, so we also have to discard the new default.

Maybe it would be possible to separate a Toggle's value from its default value, and to always update the default it it no longer matches?</issue_description>

<agent_instructions>i think this is already fixed, validate that the implementation cover this usecases</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@erikeelde Interesting conundrum! Ill give it a thought. Been missing similar thing from the exposed api so been contemplating similar problem statements lately.

Sorry for my late response (haven't had much collab in this repo so your issue was as surprising as welcome!).

Also just preparing for releasing some updated binaries - both maven artifacts and apps. App is fully rewritten to compose.

Out of interest - would you be upset ifthere is no UI facility to change scopes any more? Scopes were poorly documented and I wasnt using it much myself so I haven't readded it in the compose UI.

• Fixes Difficult to differentiate between old default, updated default and user set value #309

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.