FB-279: Sync FeatureBoard API state back to ExternalState provider if registered #79
Conversation
| } | ||
| catch (ArgumentException e) // eg. thrown due to duplicate feature key | ||
| { | ||
| _logger.LogError(e, "Failed to update flags"); |
There was a problem hiding this comment.
Should the eTag value be rolled back to its original value if exception occurs at this point (ie. during handling of the FeatureConfigurationUpdated event)?
There was a problem hiding this comment.
I am not hugely experienced in handling eTags, but isn't just using a new value fine since you are trying to compare tag values in the end?
There was a problem hiding this comment.
If the eTag retains its updated value and isn't rolled back then the code inside try block won't run again until FeatureBoard API responds back with a non 304 status (due to someone touching the feature config).
I think, at least for this exception scenario [caused by duplicate feature name appearing in FB API response), rollback is appropriate, so it keeps retrying the state update periodically.
There was a problem hiding this comment.
Tricker question is what to do if IFeatureBoardExternalState throws
ickers
force-pushed
the
bugfix/update-external-state-on-change-redux
branch
from
e22d4c4 to
171826b
Compare
| await scope.ServiceProvider.GetRequiredService<IFeatureBoardService>().RefreshFeatureConfiguration(cancellationToken); | ||
| using var scope = _scopeFactory.CreateScope(); | ||
| var updated = await scope.ServiceProvider.GetRequiredService<IFeatureBoardService>().RefreshFeatureConfiguration(cancellationToken) ?? false; | ||
| if (updated || _externalState is null) |
ickers
force-pushed
the
bugfix/update-external-state-on-change-redux
branch
from
171826b to
f475ddc
Compare
ickers
force-pushed
the
bugfix/update-external-state-on-change-redux
branch
2 times, most recently
from
c4e6c63 to
da09dd0
Compare
…gnal as async exception behavhiour is not fit for purpose
ickers
force-pushed
the
bugfix/update-external-state-on-change-redux
branch
from
da09dd0 to
fa68f9e
Compare
Relevant JIRAs: FB-279 & FB-246
Summary of changes:
Retry-Afterheader is present in response