fix(flags): surface a failed admin toggle instead of swallowing it
FeatureFlagStore.set() was try/finally with no catch. A rejected
PUT /admin/flags/{key} escaped into the `void this.store.set(...)` call site
as an unhandled promise rejection; the finally-block reload then snapped the
control back to its old value. The admin saw a toggle that silently refused
to move, with no error rendered anywhere and nothing in the state.
set() now folds through the existing runSubmit helper and returns
Result<string, void>, reloading either way so the state still reflects the
server. The page awaits it and renders the failure in an app-alert.
Found by the CQRS-light pass (CQ-002/CQ-004) as one of three mutations that
reach the raw ApiClient without producing a Result — the baseline's BL-007
inventory had missed all three.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -3738,6 +3738,10 @@
|
||||
<source>De functievlaggen konden niet worden geladen.</source>
|
||||
<target datatype="html">The feature flags could not be loaded.</target>
|
||||
</trans-unit>
|
||||
<trans-unit id="flags.set.failed" datatype="html">
|
||||
<source>De functievlag kon niet worden opgeslagen.</source>
|
||||
<target datatype="html">The feature flag could not be saved.</target>
|
||||
</trans-unit>
|
||||
<trans-unit id="flags.retry" datatype="html">
|
||||
<source>Opnieuw proberen</source>
|
||||
<target datatype="html">Try again</target>
|
||||
|
||||
Reference in New Issue
Block a user